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Section  1 


INTRODUCTION 


This  volume  describes  the  Output  Processor  (OP),  its 
various  capabilities,  and  the  language  required  to  use  it. 
OP  is  a valuable  aid  for  data  presentation. 

The  reader  will  understand  terns  used  in  this  docunent 
sore  readily  if  he  has  a general  understanding  of  NIPS  360 
PPS  file  concepts. 

This  volume  is  divided  into  the  following  sections. 

OP  Capabilities  - General  description  of  the  processor's 
capability,  the  type  of  output  produced,  and  the  nethod  used 
in  producing  this  output. 

Control  Card  Formats  - Control  cards  required  to  specify 
the  format  and  publication  of  reports  on  a variety  of  output 
media. 

Report  Specifications  Summary  - Quick-reference 
summarization  of  all  cards  used  in  Report  Instruction  Table 
(HIT)  structuring. 

Run  Deck  Formats  - Typical  sequences  of  Output  Processor 
control  cards. 

Supporting  Features  - Those  features  which  complement 
the  Output  Processor  or  are  required  for  its  operation. 

Summary  of  1410-S/360  Changes  - Significant  differences 
which  NIPS  1410  FFS  users  will  encounter  in  using  NIPS  360 
FFS. 
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Section  2 


OP  CAPABILITIES 


The  Output  Processor  is  designed  to  provide  the  user 
with  hard  copy  reports,  printed  listings,  punched  cards,  or 
■agnetic  tape  of  the  data  file  or  retrieval  answer  files. 
The  systea  enables  the  user  to  see  the  information  stored 
and  to  use  the  various  report  structuring  options  to  control 
the  output  foreat  and  alter  the  data  content  by  editing, 
subroutine  conversion,  or  arithmetic  operations. 

The  user  communicates  his  requirements  to  OP  through 
report-structuring  cards.  OP  translates  the  cards  and 
generates  machine-language  instructions  to  perform  the 
output  logic.  These  instructions  constitute  a RIT  and  may 
be  stored  on  a temporary  data  set  for  use  on  a one-run  basis 
or  on  a library  data  set  for  repeated  usage. 


2.1  Input 

Input  to  the  Output  Processor  component  may  be  a QRT/QDF 
produced  by  the  RASP  component,  or  in  Source  Direct  mode,  a 
MIPS  data  file.  When  the  data  file  is  the  input  to  OP,  the 
data  file  may  be  a single  sequential  file,  concatenated 
segments  of  a sequential  file,  an  indexed  sequential  file, 
or  S/370  virtual  storage  (VSAM)  file. 


2.2  Output 

Figures  1,2,  and  3 illustrate  the  results  which  are 
obtainable  from  the  Output  Processor. 
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2.3  Standard  Functions 

Altnough  a number  of  standard  functions  are  perforaed 
autoaatically  by  the  prograa,  there  are  standard  default 
options  which  facilitate  the  reguireaents  of  the  user.  Much 
of  this  aanual  is  concerned  with  how  one  would  aodify  a 
standard  function. 

In  preparing  the  work  for  the  OP  coaponent,  the  user 
should  arrange  events  in  the  sequence  in  which  they  occur  to 
ensure  the  desired  results.  As  illustrated  in  the  examples, 
a report  usually  consists  of  heading  and  title  lines,  data 
and  labels,  and  final  lines  and  trailers. 

Title  lines  and  final  lines  are  processed  at  the 
beginning  and  end  of  the  report,  respectively.  Headers  and 
trailers  appear  at  the  top  and  bottoa  of  a page.  In  the 
data  and  label  area,  there  are  generally  three  levels  of 
processing.  The  first  is  the  record  level;  each  tiee  a new 
record  is  made  available  in  core  storage,  certain  functions 
are  perforned  regardless  of  where  the  card  specifying  the 
function  appears  in  the  deck.  The  second  is  the  line  level, 
a grouping  of  actions  or  conditions;  at  this  level,  the 
entire  group  is  treated  as  a unit.  The  third  level  is  the 
field  level  at  which  conditions  or  actions  concern  only  that 
field. 

2.4  File  Analysis  and  Run  Optimization  Statistics 

OP  gathers  and  outputs  File  Analysis  and  Run 
Optimization  Statistics.  The  File  Analysis  Statistics  are 
defined  as  follows.  The  data  set  name  (DSNAME)  of  this  data 
set  must  be  the  data  file  name  suffixed  by  a T.  The  T is 
added  to  ISAM  and  VSAH  names;  the  S is  replaced  by  T in  SAN 
names.  To  obtain  transaction  output,  the  DSNANE  must  be 
cataloged  and  the  user  must  specify  the  volume  serial 
(VTRANS)  and  unit  (UTRANS)  in  the  execution  procedure.  The 
volume  say  be  any  direct  access  volume. 

If  the  transaction  data  set  exists  at  execution  tine, 
transactions  will  be  added  (DISP*HOD) . If  the  data  set  does 
not  exi3t,  a 5-track  data  set  will  be  dynamically  allocated. 
The  user  may  change  the  allocation  val<)e  by  overriding  the 
TRANST  DD  card  space  parameter.  Transactions  are  written  as 
fixed  length,  unblocked,  50-byte  records.  The  format 
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(fixed)  and  length  (50)  cannot  be  changed  but  the  user  nay 
change  the  blocking  factor  by  specifying  a DCB  BLKSIZE  in 
the  TBANST  DD  card  which  is  a Multiple  of  50. 

If  the  user  specifies  a DSN AUK  (TRANS)  in  the  TRANS  DD 
card,  he  aust  supply  all  paraneters  required  to  process  the 
data  set.  These  parameters  aust  confora  to  the  requireaents 
defined  above. 

The  statistics  gathered  will  be  in  the  foraat  of 
transaction  records  suitable  for  input  to  an  RM  run  to 
update  a file.  The  inforaation  consists  of  the  data  file 
naae,  coaponent  naae,  source  Module  naae,  count  of 
executions  of  the  source,  and  the  date  the  source  Module  was 
executed. 

The  Bun  Optinization  Statistics  are  initiated  through 
paraneters  entered  in  the  PARK  field  on  the  EXEC  card.  The 
breakdown  of  the  statistics  details  the  amount  of  core  used 
for  user  subroutines  and  tables,  RIT,  process  block,  I/O 
buffers,  and  access  Methods.  It  will  also  include  the 
nuaber  of  BLDL  entries  allocated  and  used,  and  the  nunber  of 
entries  required  for  each  subroutine,  table,  and  the  RIT  to 
reside  in  core.  The  aaount  of  core  required  for  each  of 
then  to  reside  in  core  is  output.  If  any  are  rolled,  this 
inforaation  * s output  with  the  nuaber  of  tines  rolled  and 
the  cause  of  the  rolling. 

Since  OP  uses  all  of  the  available  core  for  a processing 
block,  the  value  in  the  process  block  used  field  will  be  a 
ainiaua  size  necessary  to  hold  the  largest  data  record, 
fixed  set,  and  all  periodic  subsets. 

The  user  is  able  to  enter  override  paraneters  for  the 
nuaber  of  BLDL  entries  to  allocate  and  the  size  of  the 
processing  block  desired  for  the  storage  of  data  records 
durinq  OP  execution. 

The  paraneters  that  nay  be  entered  in  the  PARN  field  on 
the  EXEC  card  are  as  follows: 

ROS  - Indicates  the  Run  Optiaization  Statistics 
to  be  gathered  and  output. 


are 
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NOROS  - Omit  Run  Optimization  Statistics.  If  none  of 
the  following  parameters  are  used,  this  should 
be  oaitted  as  it  is  the  default. 

The  parameters  that  may  be  used  to  tailor  the  core 
allocation  are  as  follows: 

TCP=nK  - The  number  (n)  of  1000  (K ) bytes  requested  for 
the  process  block. 

TCB=n  - The  number  (n)  of  BLDL  entries  to  allocate. 

ICS  - Use  the  statistics  record  on  the  ISAM  data 

file  to  compute  process  blocksize.  This 
parameter  cannot  be  used  with  the  TCP 
parameter. 

For  a more  detailed  description  of  the  capability,  see 
Volume  I,  Introduction  to  File  Concepts. 

2. 5 Limitations 

The  user  of  the  Output  Processor  should  be  aware  of  the 
following  system  limits: 

40  RITs  structured  in  one  OP  run. 

10  Data  files  in  one  RIT. 

42  Sets  referenced  in  one  RIT. 

30  Subroutines  specified  in  one  RIT. 

550  Named  literals  defined  in  one  RIT. 

52  Maximum  literal  size  (named  or  unnamed). 

8192  Bytes  for  a compiled  individual  level  1 statement. 

5 Retriever  generated  work  area  values  per  set;  each 

is  one  fullword  (four  bytes)  in  length. 

There  is  no  limit  on  the  number  of  the  following  items 
which  may  be  specified: 
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Data  field  naies 
Data  lines 
Label  lines 
Header  lines 
Trailer  lines 
Record (s) 

Card  (s) 


Control  cards 
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Section  3 


CONTROL  CARD  FORMATS 


This  section  describes  the  control  card  requirements  to 
specify  the  format  and  publication  of  reports.  The  cards 
required  to  supervise  an  Output  Processor  run  are  specified 
first.  General  requirements  for  structuring  a RIT  are 
qiven,  followed  by  detailed  information  for  specifying 
reports  on  three  output  nedia--printer , card  punch,  and 
magnetic  tape. 

3.1  Output  Supervisor  Control  Cards 

The  control  cards  designed  for  use  with  the  output  * 

supervisor  are  described  in  this  subsection.  All  control 
cards,  except  where  noted,  are  in  free  format  with  the  card 
type  beginning  in  column  1;  the  other  card  entries  follow 
this  card  type  with  one  or  more  spaces  between  each  entry  or 
word.  Entries  may  be  placed  in  the  card  through  column  71. 

Any  punch  in  column  72  indicates  that  there  is  a 
continuation  card. 

If  required,  sequence  numbers  for  the  control  cards  are 
punched  in  columns  73  through  80. 

Before  describing  the  individual  control  cards  the 
general  order  of  a run  deck  will  be  described.  The  output 
Processor  executes  previously  structured  RITs  using  as  input 
either  a data  file  or  an  answer  file  generated  by  a 
retrieval.  Thus  a run  deck  may  contain  RIT  specification 
decks  or  appropriate  control  cards  to  execute  a PIT. 

Consider  a run  deck  as  having  two  parts  separated  by  a 
SOURCE  card.  The  order  would  be: 
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FIT  specification  decks 

SOURCE  card 

Publish  control  cards 

3.1.1  CREATE  Card  (RITID,  STORE,  DEBUG,  BOOL) 

Each  RIT  to  be  structured  Bust  be  preceded  by  a CREATE 
card.  The  CREATE  card  identifies  the  RIT  by  assigning  an 
RITNAHE  vhich  aust  confora  to  the  NIPS  naaing  conventions 
(section  2.6.3  Voluae  I,  Introduction  to  Pile  Concepts)  and 
directs  the  disposition  of  the  generated  prograa.  Peraanent 
or  standard  RITs  are  added  to  or  replace  existing  RITs  on  a 
peraanent  library  and  reaain  there  until  deleted  by  the 
user.  Teaporary  RITs  are  placed  on  a teaporary  library  and 
are  released  at  the  end  of  the  current  run. 

This  card  aay  also  be  used  to  specify  two  special 
operators,  DEBUG,  which  indicates  that  the  structure  deck  is 
to  be  checked  for  errors  only,  and  a BOOL  option  which 
indicates  that  Boolean  logic  is  to  be  used  with  conditions. 

The  CREATE  card  has  a positional  keyword  foraat.  The 
allowable  keywords  are  as  follows: 

CREATE  - Identifies  the  card  and  starts  in  ccluan  1. 

RITID  - Is  the  keyword  for  RIT  .dentif ications. 

STORE  - Is  the  keyword  for  disposition.  Disposition 
can  have  the  values  PERM-OLD  to  replace  a peraanent 
RIT,  PER H-NEH  to  add  a peraanent  RIT  and  TEMP  for  a 
teaporary  RIT. 

DEBUG  - Designates  error  check  only. 

This  option  provides  for  validation  of  a run  deck 
without  building  a RIT.  The  STORE  paraaeter  should  not 
be  used  if  DEBUG  is  specified. 

BOOL  - Used  as  the  last  paraaeter  to  indicate  Boolean  logic 
used. 

Note:  If  the  keyword  RITID*  is  not  first,  the  value 

specified  is  assuaed  to  be  the  naae  of  a RIT  to  be 
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structured,  and  the  following  options  are  taken:  storage 
of  the  RIT  on  the  peraanent  library  as  a change  and 
BOOLEAN  logic.  When  the  keyword  RITID  is  specified,  the 
second  entry  nust  be  STORE  or  DEBUG;  if  any  other  value 
is  specified,  the  DEBUG  option  is  assuned  and  the  RIT 
will  only  be  checked  for  specification  errors. 

Exanple: 

a.  CREATE  RITAP 

RIT  AF  will  be  structured  and  stored  on  the 
peraanent  library  as  a change.  The  Boolean  logic 
option  is  assuned. 

b.  CREATE  RITID*RITNA  HE  STORE=PERH-OLD 

Structure  the  RIT  RITNAHE.  The  store  option  is 
used  to  replace  a peraanent  RIT  on  a library. 

C.  CREATE  RITID=RITNA  HE  STORE=PEPH-NEN 

Sane  as  exanple  b except  that  the  newly  structured 

RIT  is  added  to  the  peraanent  library.  i 

d.  CREATE  RITID=RITNA  HE  STORE=TEHP 

The  RIT  will  be  added  to  the  teaporary  library  and 
deleted  on  coapletion  of  the  step. 

e.  CREATE  RITID=RITNAHE  DEBUG 

A debug  pass  will  be  nade  through  the  edit  and 
translator  to  check  for  specification  errors.  No 
RIT  will  be  structured  or  stored. 


f.  CREATE  RITIT-RITNAHE  STORE=PERH-NEW  BOOL 
Specifies  Boolean  logic  option. 
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3.1.2  SOURCE  Card  (DIRECT,  RETRIEVAL) 

The  last  RIT  specification  deck  (if  any)  is  followed  by 
a SOURCE  card,  if  reports  are  to  be  published  during  the 
sane  job.  There  are  two  sources  of  input  data  to  OP. 

SOURCE  DIRECT  - Used  when  data  is  to  be  read  directly 
froe  the  data  file  without  having  previously  been  qualified 
by  retrieval.  It  aust  be  followed  by  at  least  one  PUBLISH 
card. 


Example: 

To  run  directly  against  a data  file  and  to  publish  the 
report  produced  by  RIT  ZILCH. 

SOURCE  DIRECT 
PUBLISH  RITID=ZILCH 

SOURCE  RETRIEVAL  - Used  when  data  is  read  froe  a file 
qualified  and  produced  by  the  Retrieval  progran.  Operating 
in  a batch  query  environment,  one  can  expect  more  than  one 
set  of  answers  on  the  source  data  set.  If  all  answer  sets 
are  to  be  published  using  the  RITs  specified  at  retrieval 
tiae  and  not  requiring  any  additional  input  parameters,  no 
other  control  cards  are  required.  This  is  referred  to  as 
the  "nonselect"  node. 

Example: 


SOURCE  RETRIEVAL 

This  card  alone  would  indicate  that  all  answer  sets  on  the 
input  data  set  were  to  be  published  by  the  retrieval 
designated  RITs  that  are  on  the  Permanent  Library.  If  only 
designated  answer  sets  are  to  be  published,  or  additional 
parameters  are  to  be  provided,  the  SOURCE  card  will  be 
followed  by  at  least  one  PUBLISH  card  per  report  published. 
This  is  referred  to  as  the  "select"  node. 
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Example: 

SOURCE  RETRIEVAL 
PUBLISH  ANSID=17.. . . 

Answer  set  number  17  would  be  processed. 


3.1.3  PUBLISH  Card  (PITID,  SPECIAL,  ANSID,  COVERPAGE, 

PAGENO,  BODYLINES , COPIES,  CLASS,  PAFAH,  DEBUG, 

DATE) 

The  PUBLISH  card  is  used  to  provide  the  OP  Supervisor 
with  the  RIT  naae,  the  answer  set  ID,  and  a cover  page  code. 

The  PUBLISH  card  is  free  format,  keyword  in  fora. 

Columns  73-74  aust  be  blank.  All  paraaeters  required  by  the 
Output  Processor  can  be  entered  using  this  card. 

) 
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Definition 


PITID=RITNAHE 


SPEC1AL=RITNAHE 


ANSID=NN 


AN  SID=NN/RRR 


COVERP  AG E=CDW 


PAGENOsNN 


BODILINES*NN 


Identifies  name  of  RIT 
stored  on  Permanent 
Li  brar  y. 

Identifies  name  of  RIT 
stored  on  Temporary 
Library. 

Identifies  a set  of 
answers  to  be  published. 
NN  is  the  1-  to  4-digit 
query  number  used  at 
retrieval  time.  Note 
that  for  multiple 
executions  of  the  same 
query,  the  retrieval 
component  will  suffix  the 
query  number  with  an 
alpha  character  for  the 
second  and  subsequent 
executions.  The  suffixes 
begin  with  the  letter  "A" 
and  must  be  included  as 
part  of  the  ANSID  when 
applicable. 

Identifies  a set  of 
answers  to  be  published. 
NN  is  the  query  number  as 
defined  above  and  RRR  is 
the  secondary  (RIT)  ID 
used  at  retrieval  time. 

Designates  the  cover  page 
code  to  be  used  for  the 
report.  (Optional.) 

Designates  a starting 
page  number;  defaults  to 
1.  (Optional.) 

Allows  number  of  body 
lines  per  page  to  be 
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COPIES=N  N 


CL AS S= UNCLASSIFIED 


PABAM='P AR AM  EXAMPLE' 


DEBUG*NN 


changed  at  run  time; 
defaults  to  50. 

(Optional . ) 

Allows  number  of  copies 
to  be  specified;  defaults 
to  1,  (Optional.) 

Classification  of  output. 

Note  that  if  there  are 
embedded  blanks  the 

classification  must  be 
enclosed  in  (quote) 
signs. 

Parameter  allowing  the 
user  to  introduce  up  to 
60  bytes  of  information 
to  the  PIT  at  PIT 
execution  time.  Same 

rule  for  embedded  blanks.  J 

Used  at  execution  time  to 
allow  the  user  to 
designate  the  number  of 
data  blocks  to  be  passed 
against  the  RIT.  The 
maximum  number  specified 
is  32,767.  When  N is 
exhausted,  an  end-of-file 
or  end-of-answer  set  is 
simulated.  When  data 
interrupts  occur  and  a 
dump  is  required,  the 
DEBUG  parameter  can  be 
used.  If  there  is  a 
debug  count,  the  first 
data  interrupt  will  cause 
a SYSABEND  dump.  when 
using  this  option,  make 
sure  the  debug  count  is 
high  enough  to  get  to  the 
record  causing  the  data 
interrupt. 
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DATE=DDMMHY YHHHH  Allows  user  to  specify  up 

to  an  11-character  date. 
Saie  rule  for  embedded 


blanks . 

Exaaple:  72 

PUBLISH  ANSID=1  RITID=RITEXfIP  COVERPAGE=CDW  X 

PAGENO=101  BOOYL IN  ES=40  C0PIES=2  X 

CLASS3 ' VER  Y UNCLASSIFIED*  DATE3' 15FEB68*  X 

PAR  A H= • THI S IS  AN  EXAMPLE  OF  THE  PUBLISH  CARD*  X 
DEBUG=10 


Several  of  the  PUBLISH  card  paraneters  warrant  further 
explanation. 

ANSID  eay  specify  a query  nuaber  or  a query  nuaber  and 
a secondary  ID.  If  the  retrieval  produced  several  sub- 
answer sets  and  ANSID3NN  is  used,  all  subanswer  sets  will  be 
produced.  If  a particular  subanswer  set  is  required  the 
fora  ANSIDsN N/RRR  aust  be  used. 

Execution  of  a teaporary  RIT  can  be  specified  only  via 
this  fora  of  PUBLISH  card.  This  includes  retrieval- 
designated  RITs. 

Care  should  be  used  in  specifying  the  query  nuaber  for 
publishing  aultiple  executions  of  the  sane  query  by  the 
retrieval  conponent.  The  second  and  succeeding  query 
executions  result  in  the  query  nuaber  beinq  suffixed  with  an 
alpha  character.  Suffixing  begins  with  "A"  and  progresses 
sequentially  for  each  execution  of  the  sane  query.  For 
exaaple,  if  query  nuaber  "22"  was  executed  three  tines  (with 
different  replaceaent  values  using  the  RASP  skeleton 
capability) , the  first  answer  set  would  be  specified  as 
ANSIbs22 , the  second  as  ANSID322A  and  the  third  as 
ANSID=22R-  The  specification  of  the  subanswer  set  (RIT  ID) 
reaains  unchanged. 
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Publication  of  an  answer  set  can  be  requested  any  nuaber 
of  times  in  the  sane  run.  The  PUBLISH  control  cards  can  be 
in  any  order.  Answers  are  published  in  answer  file  order. 

Example: 


PUBLISH  ANSI D= 1 RITID= RIT NAME 
PUBLISH  ANSI D= 1 SPECIAL=ZILCH 

Ihe  CLASS  parameter  is  compared  against  the  file 
classification  and  if  not  equal,  or  if  the  classification 
parameter  is  not  specified,  a warning  page  will  be  printed 
along  with  a console  diagnostic  to  the  operator. 

The  DEBUG  parameter  is  a useful  tool  in  debugging  a FIT. 
The  analyst  can  "run"  against  a real  data  file  or  answer 
set,  and  limit  the  amount  of  output  to  a specified  nuaber  of 
biocxs  until  checked  out. 

COVERPAGE  is  a series  of  codes  providing  a special  cover 
page  for  the  report  containing  classification  downgrade  and 
warning  information  in  the  format  COVERPAGE  = CDMS. 

In  compliance  with  the  Executive  Order  11652,  8 March 
1972  which  establishes  current  policies  governing 
classification,  downgrading  and  declassification  of  official 
information,  the  following  coverpage  features  are  available 
for  the  user's  requirements. 

The  codes  and  their  results  on  the  cover  page  are  as 
follows: 
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The  classification  code  is  represented  by  'C' 
example. 


in  the 


C - Code  Data 


U 

Unclassi f ied 

c 

Confidential 

s 

Secret 

T 

Top  Secret 

J 

Top  Secret  - 

Crypto 

I 

Top  Secret  - 

Special  Intelligence 

H 

Top  Secret  - 

Category  10 

G 

Top  Secret  - 

Category  7 

F 

Top  Secret  - 

Slop 

E 

Top  Secret  - 

SIOP  - ESI 

Note:  The  following  paragraphs  are  printed  with 
Code  P — Top  Secret  - SIOP. 

Special  handling  reguired--not  releasable  to 
foreign  nationals  or  their  representatives. 

This  document  contains  information  affecting  the 
National  Defense  of  the  United  States  within  the 
meaning  of  the  Espionage  laws.  Title  18,  U.S.C., 
Sections  793  and  794.  The  transmission  or  the 
revelation  of  its  contents  in  any  manner  to  an 
unauthorized  person  is  prohibited  by  law. 

The  downgrade  code  is  represented  by  'D'  in  the  example. 
The  absence  of  a valid  code  causes  the  program  to  bypass  the 
printing  of  the  cover  page.  This  does  not  cause  the  OP  run 
to  be  terminated.  Valid  codes  and  their  corresponding 
results  are  as  follows: 
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D - Code  Data 


DOWNGRADE  TO: 

SECRET  ON 

CONFIDENTIAL  ON' 
DECLASSIFY  ON 


CLASSIFIED  BY:  

EXEMPT  FROM  GENERAL  DECLASSIFICATION  SCHEDULE 
OF  EXECUTIVE  ORDER  11652  EXEMPTION 
DECLASSIFY  ON 


C.  CLASSIFIED  3 Y 

SUBJECT  TO  GENERAL  DECLASSIFICATION  SCHEDULE  OF 
EXECUTIVE  ORDER  11652  ATUOHATICALLY  DOWNGRADED 
AT  TBO  YEAR  INTERVALS  DECLASSIFY  ON  31 
DECEMBER 

The  warning  code  is  represented  by  • N*  in  the  exasple. 
This  cod9  is  optional  and  is  used  to  designate  that  a 
special  warning  should  be  printed  on  the  cover  page.  The 
warning  codes  and  their  corresponding  results  are  as 
follows: 

H - Code  Data 


Controlled  dissesination 

Formerly  Restricted  Data,  Section  144B, 
Atosic  Energy  Act,  1954 

Restricted  Data,  Atosic  Energy  Act,  1954 

Special  Handling  Required,  not  releasable 
to  foreign  nationals  or  their  representa- 

t iV9S 

Reproduction  of  docuaent  in  whole  or 
part  prohibited  except  with  pernission 
of  issuing  office  or  higher  authority 
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F Special  Handling  Pequired,  not  releasable 
to  foreign  nationals  or  their  repre- 
sentatives, reproduction  of  document  in 
whole  or  part  prohibited  except  with 
permission  of  issuing  office  or  higher 
authority 

The  special  instruction  code  is  represented  by  'S'  in 
the  example.  It  is  used  to  designate  one  of  the  following 
instructions: 

X NATIONAL  SECURITY  INFORMATION 

UNAUTHORIZED  DISCLOSURE  SUBJECT  TO 
CRIMINAL  SANCTION 

(Note:  This  instruction  is  for  classified  information  which  is 

furnished  to  persons  outside  the  Executive  Branch) 

b WARNING  NOTICE  - SENSITIVE  INTELLIGENCE  SOURCES 

AND  METHODS  INVOLVED 

Note:  For  all  codes  the  letter  "H"  (for  none)  nay  be  used  in 

any  position  to  omit  blocks  of  options. 

3.2  Report  Structuring  Control  Cards 

The  following  is  a summary  of  OP  control  cards  used  for 
structuring  a RIT.  A FILE  card  identifies  the  file  for  the 
specifications  to  follow.  A FORMAT  card  describes  the 
format  of  tape,  card,  or  printed  listings  and  the  limits  of 
each  if  required  (e.q.,  blocksize,  number  of  positions  per 
line  for  the  specifications  to  follow)  . 

Either  a FILE  card  or  FORMAT  card  must  appear  first. 
This  will  allow  multiple  files  by  format,  or  multiple 
formats  by  file. 

Omit  - Followed  by  conditional  logic;  used  to  omit 
presentation  of  a record. 

Stop  - Followed  by  conditional  logic;  used  to  stop  the 
report. 

Header  - Describes  information  that  will  appear  at  the 
top  of  each  page  of  printed  output. 
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Titleline  - Describes  information  that  will  be  printed 
at  the  outset  of  the  report  (albeit  after  header's 
information)  only. 

Overflow  - Information  that  will  be  printed  (following 
header  information)  if  the  first  line  (LINE1)  of  the  RIT 
is  not  the  line  to  be  printed  after  the  printer  ejects 
to  a new  page.  (See  figure  4 for  an  example.) 


HEADER 


Title 

Linel 
Line2 
Line  3 
Line4 


Overflow 

Line5 

Linel 

Line2 

Line3 


Page  1 


TRAILER 

HFADER 

Page  2 


Figure  4.  overflow  Line 


Line  - The  primary  method  for  specifying  data 
information  on  the  printed  page.  In  a RIT  calling  for 
multiple  sets  of  line  specifications,  the  lines  will  be 
printed.  Periodic  information  will  be  repeated  until 
all  such  information  is  printed,  going  through  a 
complete  cycle  for  each  record. 

Label  - Associated  or  supplementary  information  attached 
to  a line;  an  associated  label  will  be  printed  only  if 
its  line  is  printed. 
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Finalline  - Information  to  be  printed  only  at  the 
termination  of  the  report. 

Trailer  - Information  that  mill  appear  at  the  bottom  of 
each  page  of  printed  output. 

The  following  paragraphs  discuss  in  detail  the  report 
specifications  necessary  to  generate  a normal  report  format. 
The  discussion  of  the  report  specifications  introduce 
examples  to  illustrate  the  specifications.  Specifications 
for  puncn  card  and  magnetic  tape  format  are  shown  in 
sections  3.4  and  3.5  respectively. 

3.2.1  Specification  of  the  Data  Pile 

The  example  used  here  is  a single  file  report  and  the 
first  specification  should  be  the  file  mnemonic  to  which  the 
report  pertains.  This  is  true  whether  more  than  one  format 
(print,  punch,  or  tape)  is  to  be  specified  or  if  the  report 
is  to  be  printed  only,  as  in  this  example.  Multifile 
reports  must  have  the  file  mnemonic  specified  for  each  set 
of  specifications  dealing  with  that  file.  Thus,  for  this 
example,  the  file  anemonic  would  be: 

FILE  TEST360 

The  file  mnemonic  specified  on  the  FILE  statement  must 
correspond  to  the  unqualified  data  set  name  or  the  last 
segment  of  a qualified  data  set  name  designated  in  the  JCL. 


3.2.2  Formatted  Reports 

The  Output  Processor  can  provide  formatted  reports 
printed  on  all  sizes  of  printer  paper,  punched  in  cards,  or 
written  on  magnetic  tape.  To  indicate  the  type  of  output 
desired  and  to  specify  the  exact  format,  report 
specification  cards  are  used. 

3.2.3  Report  Instruction  Table  (RIT) 

Report  specification  cards  are  the  input  to  the  Report 
Structuring  program  of  the  Output  Processor.  The  cards  are 
analyzed  and  the  specifications  are  built  into  a RIT  and  any 
errors  are  printed  for  review  by  the  user.  Some  errors  are 
considered  as  diagnostics  only  and  will  allow  the 
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compilation  of  the  RIT  to  be  completed  while  others  will 
cause  the  run  to  be  terminated  before  the  assembly  phase. 
In  some  instances  assumptions  will  be  made  which  will  allow 
the  RIT  to  be  structured;  in  any  event,  all  the  errors  and 
diagnostics  are  listed. 

3.2.4  Report  Specification  Cards  - General 

Output  media  are  indicated  on  format  cards  along  with 
specifications  for  overall  format  control.  The  file 
mnemonic  to  which  the  specifications  pertain  is  indicated  on 
the  FILE  card. 

Under  normal  conditions  the  next  item  for  consideration 
is  tne  layout  of  the  lines,  cards,  or  tape  records,  the 
specification  of  the  positions  of  the  data,  and  any  data 
manipulation  or  other  output  requirements.  Therefore,  any 
header  lines  are  defined  (HEADER  card)  followed  by  the  data 
to  go  on  each  line,  card,  or  tape  record  (LINE,  CARD,  or 
RECORD  cards,  respectively).  Such  operations  as  edits, 
conversion  tables,  output  subroutines,  calculations,  or 
logical  output  requirements  are  also  specified  on  these 
cards.  Label  lines,  which  are  dependent  upon  the  output  of 
data  lines,  nay  be  specified  on  LABEL  cards.  Finally,  the 
trailer  lines  are  defined  (TRAILER  card). 

The  normal  spacing  between  lines  can  be  indicated  on  the 
PORMAT  card;  other  spacing  can  be  indicated  by  SPACE  cards. 
The  format  of  the  report  can  also  be  controlled  with  the 
carriage  control  tape  by  the  use  of  the  SKIP  card,  and  an 
ejection  to  a new  page  by  the  EJECT  card. 

The  above  card  types  are  discussed  in  detail  in  the 
following  sections  along  with  a discussion  of  more  complex 
reports  and  additional  specifications  necessary  to  handle 
these  reports. 

3.2.5  Card  Layout 

All  specification  cards,  except  where  noted,  are  in  free 
format  with  the  card  type  as  the  first  entry  on  the  card. 
The  succeeding  entries  on  each  card  are  separated  by  one  or 
more  blanks.  The  entries  nay  be  placed  through  column  71  of 
the  card  and  in  certain  cases  it  is  necessary  to  continue 
the  entries  on  the  next  card.  If  this  is  required,  each 
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card  which  has  specifications  continuing  on  a following  card 
■ust  have  a punch  in  column  72  and  the  continuing  card  aust 
have  tho  card  type  as  the  first  entry  (this  grouping  is 
limited  to  three  cards) ; otherwise,  column  72  aust  be  blank. 
Only  three  continuation  cards  may  be  used  providing  a total 
of  four  cards  for  the  compute  statement. 

Columns  73-80  are  provided  for  identification  and  card 
seguencing.  It  is  recommended  that  columns  73-76  be  used 
for  deck  identification.  Columns  77-80  are  for  the  card 
seguence  number,  A sequence  check  is  performed  on  columns 
77-00  unless  these  columns  of  the  first  card  contain  blanks. 
However,  any  errors  detected  will  not  affect  the  analysis  of 
the  cards.  If  the  sequence  number  is  blank  or  if  a sequence 
error  is  found,  the  Output  program  will  insert  a sequence 
number  ending  with  S and  all  further  references  to  the  card 
will  be  with  this  number. 

All  output  positions  specified  for  data  fields  or 
literals  aust  be  low-order  (rightmost)  positions. 

Comment  cards  (indicated  by  an  asterisk  in  column  1)  may 
be  inserted  anywhere  in  the  deck. 


3.2.6  Control  of  Page  Format 

The  format  of  a page  is  specified  through  the  use  of  a 
FORMAT  card.  For  a printed  format,  the  card  will  always 
contain  the  word  PRINT  following  the  word  FORMAT. 


> 


FORMAT  PRINT 


body  lines  are  the  number  of  lines  per  page  exclusive  of 
header  and  trailer  lines.  After  determining  the  page  layout 
with  the  header  and  trailer  lines  and  their  associated 
spacing,  the  number  of  body  lines  desired  per  page  (the 
number  of  lines,  including  spacing,  between  the  last  header 
line  and  the  first  trailer  line)  may  be  specified.  This  is 
indicated  by  including  the  term  LINES  on  the  FORMAT  card 
followed  by  the  number  of  body  lines  required.  If  the 
LINES  entry  is  omitted,  the  standard  mode  of  50  body  lines 
will  be  assumed. 


FORMAT  PRIN^  LINES  55 

I - 
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Normal  Spacing  Between  Lines 

The  option  is  provided  to  specify  an  overall  spacing 
between  lines  for  the  report.  The  naximum  spacing  that  can 
be  specified  is  four  spaces.  The  spacing  indicated  will  be 
used  by  the  output  proqram  unless  a SPACE  card  is  used  to 
override  this  spacing. 

The  spacing  factor  is  indicated  by  including  the  tern 
SPACE  on  the  FORMAT  card  followed  by  the  nuaber  of  spaces 
required . 


FORMAT  PRINT  SPACE  2 

The  above  example  specifies  double  spacing  and  becomes 
the  normal  spacing.  If  this  entry  is  omitted,  single 
spacing  will  be  assumed. 

Paper  width 

This  option  is  included  to  provide  additional  error 
checking  for  the  print  output  positions  "specified.  The 
paper  size  is  specified  by  including  the  term  SIZE  on  the 
FORMAT  card  followed  by  the  number  of  print  positions  for 
the  width  of  the  paper  used  for  the  report. 


FORMAT  PRINT  SIZE  105 

The  above  example  specifies  the  width  of  the  report  to 
be  105  print  positions.  If  this  entry  is  omitted,  the 
standard  132-position  paper  will  be  assumed. 

The  above  specifications  can  be  entered  on  the  format 
card  in  any  order  after  the  word  PRINT.  For  example  : 

FORMAT  PRINT  SPACE  2 SIZE  105  LINES  55 

The  above  example  combines  all  three  options. 

3.2.7  Specification  of  System  Labels  (OPDATE,  PAGENO, 
CLASSIF,  BODYLINES,  PARAM,  PSCTn,  WORKn) 

The  Output  Processor  provides  the  ability  to  specify 
certain  parameters  when  the  report  is  produced.  These 
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parameters  are  specified  through  the  use  of  system  labels  at 
the  tine  the  PIT  is  compiled,  and  with  their  respective 
output  control  cards  at  execution  time. 

OPDATE 

This  term  defines  a field  which  holds  a specified  date 
which  is  to  be  used  for  this  report.  It  is  an  11-character 
field  that  can  be  entered  on  a date  card  at  the  time  a 
report  is  produced.  The  Output  program  will  use  the  date  as 
specified  on  the  control  card.  If  the  OPDATE  card  is 
omitted  at  execution  time,  the  Output  program  will  use  the 
system  date,  in  the  form  ' DD  HUH  YYYY*. 

PAGENO 

This  term  defines  a 6-digit  field  which  holds  the 
current  page  number. 

CLASSIF 

This  term  defines  a 32-character  field  which  holds  the 
classification  for  this  report.  If  the  CLASSIF  card  was 
omitted,  the  field  "CLASSIF"  will  be  blank. 

BODYLINES 

This  term  identifies  a 2-digit  counter  that  holds  the 
current  number  of  body  lines  remaining  on  a page. 

PARAfJ 

This  term  defines  a 60-character  area  into  which  data 
can  be  introduced  to  the  PIT  at  execution  time.  The  data 
can  be  used  for  control  purposes  or  data  presentation. 

PSCTn 

This  tern  defines  a field  which  holds  a count  of  subsets 
loaded  into  the  processing  block.  A HIT  which  references 
PSCTn  will  reference  this  count.  Note  that  only  subsets 
used  by  the  RIT  are  loaded;  i.e.,  if  the  FIT  uses  only 
subsets  flagged  in  a retrieval  run,  nonflagged  subsets  will 
not  oe  loaded.  The  set  number  is  designated  by  n.  The  PSCT 


OUTPUT  PtfOCESSQP  (OP) 


field  may  be  referenced  only  in  MOVE  expressions,  on  print 
positions,  or  in  conditionals, 

UORKn 

This  special  term  must  be  used  when  referencing  data 
values  (work  areas)  passed  to  the  Output  Processor  by  the 
RASP.  There  are  five  work  areas  (WOPK1  through  H0RK5) . 
Each  area  is  one  fullword  (four  bytes)  in  length.  The  work 
areas  are  set  associated  and  are  processed,  using  the  same 
rules  and  restrictions  as  file  data  fields.  The  user  must 
specify  the  set,  a name  for  each  work  area,  the  output 
length  and  the  data  mode.  Specification  of  literals  or  work 
areas  in  the  general  case,  and  this  special  case,  is  made  in 
a DEFINE  statement  as  described  in  paragraph  3.3.4. 

3.2.8  Conditional  Statements  (IF) 

Many  of  the  specifications  to  be  described  may  be 
conditional  and  nay  be  expressed  similar  to  the  terms  in 
retrieval  language.  Conditional  statements  are  of  the 
general  form: 

...  If,  parameter,  condition,  parameter,  AND/OR, 

parameter,  condition,  etc. 

These  conditional  expressions  are  used  to  condition  the 
printing  of  fields,  lines,  or  results  of  computations.  It 
should  be  noted  that  only  conditions  of  level  2 will 
condition  the  writing  of  a line,  card,  or  record. 
Conditions  at  levels  4 or  5 on  a line,  card,  or  record 
statement  condition  the  moving  of  data  or  the  action 
specified  on  the  statement  but  not  the  writing  of  the  output 
data. 


Generally,  the  parameters  may  be  any  field  or  group  name 
except  that  both  parameters  must  not  be  periodic  fields  or 
groups  from  different  sets.  The  last  parameter  nay  also  be 
a previously  defined  literal,  an  alphabetic  literal 
('literal')*  4 numeric  literal,  or  binary  literal.  The 
first  parameter  must  be  a previously  defined  literal  or 
field. 

Note:  Crossing  set  boundaries  between  action  and  condition 
creates  an  illogical  statement.  A fixed  set  conditioned  on 
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any  periodic  is  permitted.  A periodic  set  aay  be 
conditioned  on  the  same  periodic.  A periodic  set 
conditioned  on  a different  periodic  set  is  not  permitted. 
This  will  generate  an  error  condition.  An  exaaple  of 
illegally  crossing  set  boundaries  is:  LINES  20  MEQPT  IP 
PLAN  EQ  2222  (where  MEQP'’’  and  PLAN  are  in  different  periodic 
sets) . 


The  conditions  which  aay  be  used  are  siailar  to  those 
used  in  retrieval  and  are  listed  as  follows: 


Negation 

Greater 

Less  Than 

Equal  To 

Change  Pi 

Etsiiaas. 

NOT 

GREATER 

LESS 

EQUAL 

CHANGE 

NE  (a  special 

LATER 

EARLIER 

EQUALS 

CHANGES 

case  of  not 

equal) 

APTER 

BEFORE 

EQUALING 

CH 

GT 

LT 

EQ 

Note:  See  table  2 of  section  4 for  a coaplete  list. 


The  CHANGE  operator  provides  OP  with  the  capability  to 
perform  specified  actions  when  values  change  from  a previous 
state.  The  previous  value,  used  as  the  basis  for  CHANGE 
logic,  is  updated  each  time  the  tera  containing  IF  CHANGE  is 
processed.  It  is  not  updated  when  the  tera  has  been 
bypassed  in  the  logical  processing  of  all  conditions/teras 
in  the  RIT.  Bypassing  is  possible  when  multiple  change 
teras  are  connected  by  an  OR,  and  the  user  should  understand 
that  CHANGE  logic  aay  not  be  based  on  the  value  in  the 
iaaediately  proceeding  record.  If  this  is  not  acceptable, 
flags  aay  be  substituted,  for  exaaple: 

MOVE  TO  PLAG1  IP  SERV  CHANGES 


LIN  E 1 4 IF  PLAG1  EQ  'X' 


29 


. 


OUTPUT  PROCESSOR  (OP) 


LIN  E 14  HOVE  • • TO  FLAG1 

In  addition  to  the  above  conditions,  OP  Bakes  use  of  two 
other  special  purpose  conditional  operators.  These  are 
CONTAINS  and  ABSENT. 

The  CONTAINS  operator  provides  OP  with  a text  scan 
capability  that  recognizes  field  values  wherever  they  occur 
within  a fixed  or  variable  length  field  or  variable  set,  A 
scan  of  a specified  field  will  occur  in  a shifting 
coaparison  technique  to  deteraine  whether  the  condition  is 
satisfied.  In  this  Banner,  the  user  aay  access  variable 
fields,  variable  sets,  and  data  that  is  in  any  portion  of  a 
fixed-length  alpha  field.  A conditional  stateaent  using 
CONTAINS  is  written  in  the  following  Banner: 

...  IF  fieldnaae  CONTAINS  parameter. 

When  using  the  ABSENT  operator,  a condition  is  satisfied 
wnen  there  are  no  subsets  in  the  referenced  set.  The 
referenced  set  aay  be  either  a periodic  or  variable  set.  A 
conditional  stateaent  using  the  ABSENT  operator  is  written 
in  the  following  Banner: 

...  IF  fieldname  ABSENT. 

Certain  other  (noise)  wcrds  aay  be  included  to  improve  read- 
ability. 

Noise  Words 
IS 

THAN 

THE 

TO 

The  conditional  statement  will  be  tested  using  the  S/360 
logical  collating  sequence  unless  both  parameters  are 
numeric.  In  using  a conditional  stateaent,  standard  rules 
of  truncation  and  padding  are  used.  If  both  paraaeters  are 
numeric,  an  algebraic  comparison  will  be  used. 
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Two  Methods  for  logically  processing  conditions  are 
provided.  They  are  referred  to  as  "standard"  and  "Boolean." 

The  Output  program  examines  the  "standard"  conditional 
stateaent  in  the  following  Banner: 

a.  If  an  AND  or  IF  tera  is  satisfied,  the  following 
OR  terns  are  not  processed.  The  next  tera  to  be 
checked  is  another  AND  tera. 

b.  If  an  AND  or  IF  tera  is  not  satisfied,  succeeding 
OR  terns  are  examined  until  one  is  satisfied.  The 
renaining  OR  terns  are  not  checked,  and  the  next 
tern  to  be  checked  is  the  next  AND  term. 


c.  If  an  AND  or  IF  tera  is  not  satisfied,  and  no 
OR  tern  is  satisfied  prior  to  another  AND  tera 

or  prior  to  the  end  of  the  expression,  the  condi- 
tion fails. 

d.  If  the  end  of  the  lcgic  condition  is  reached  and  the 
preceding  AND/OR  group  is  satisfied,  the  logic 
condition  is  satisfied. 


i 


The  following  exanples  are  given  to  illustrate  the 


above: 

£&£££££ion 
IF  A AND  B 
IF  A 0R  B 
IF  A OR  B AND  C 


Interpretation 

Both  A and  B must  be  true. 

Either  A or  B nust  be  true 

C nust  be  true.  Either  A 
or  B nust  also  be  true. 


IF  A AND  B OR  C AND  D A nust  be  true,  D must 

be  true,  and  either  B or  C 
nust  be  true. 

"boolean"  logic  processing  differs  fron  the  standard  RIT 
conditional  logic  processing.  The  ANDs  tend  to  join  and  ORs 
tend  to  separate.  The  following  logical  truth  tables 
illustrate  the  processing  of  the  Boolean  logic: 


i 


\ 


T 


i 


' 


1 


V 


i 
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Expression 
IP  A AND  B 
IP  A OR  B 
IP  A AND  B OR  C 


Results 

Both  A and  B must  be  true. 

Either  A or  B must  be  true. 

Both  A and  B must  be  true, 
or  C Bust  be  true. 


The  sequence  of  processing  for  a condition  statement  is 
as  follows: 


a.  Starting  with  the  first  clause  (AND),  each  AND 
clause  is  processed  until:  (1)  the  end  of  the 
statement;  (2)  a false  condition  is  found;  or  (3) 
an  OR  is  reached. 

b.  If  the  AND  (string)  is  terminated  because  of  a 
false  condition,  processing  resumes  at  the  next  OR. 
If  there  is  not  another  OR  before  the  end  of 
statement,  the  condition  statement  is  false. 

c.  If  the  AND  (string)  is  terminated  because  of 
reaching  the  end  of  statement  or  an  OF  is  reached, 
that  statement  is  true. 

The  difference  between  the  standard  conditional  logic 
and  Boolean  logic  is  illustrated  by  the  examples  below. 


StaadaJLd-Cgfiditjgnal-Logic 

filEISSSjon 
IP  A AND  B OR  C 

IP  B AND  A OF  C 

fiieisssiss 


Interpretation 

A must  be  true;  either  B 
or  C must  be  true. 

B must  be  true;  either  A or 
C must  be  true. 

Interpretation 


IP  A AND  B OR  C A and  B must  be  true,  or 

C must  be  true. 


J 
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I. 


i 


i 


I 


IF  B AND  A OR  C B and  A Bust,  be  true,  or 

C Bust  be  true. 

The  interchanging  of  A and  B with  the  standard  logic 
gives  different  results  whereas  with  the  Boolean  logic,  it 
is  the  saie. 

All  logic  for  a given  RIT  will  be  processed,  using  the 
saae  logic.  The  standard  logic  will  be  the  non-Boolean 
type;  however,  the  user  say  optionally  specify  the  use  of 
Boolean  logic  on  the  CPE ATE  card  (see  3.1.1). 


3.2.9  Header  Lines  (HEADERn)  and  Trailer  Lines  (TRAILERn) 

Header  lines  are  specified  following  the  FORMAT  card. 
These  are  nondata  lines  printed  at  the  top  of  each  page. 
Header  lines  will  normally  contain  systen  labels  and  other 
descriptive  information  concerning  the  report. 

The  general  form  for  the  header  specification  is: 

soafllglanai-glaisasat 

HEADERn  47  'ACTUAL  LABEL' 

47  System  label 
47  literal 

n is  the  header  level  nuaber 

The  labels  or  literals  are  located  on  the  header  line  by 
specifying  a low-order  (rightmost)  print  position  for  each. 

HEADEP1  71  'UNCLASSIFIED* 

HEADEP1  103  * PARE' 

HEADEP1  110  PAGENO 

These  specifications  will  cause  a line  to  be  formatted 
with  the  terms  UNCLASSIFIED  in  position  71  and  PAGE  in 
position  103.  The  third  example  for  HFADEPl  demonstrates 
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: 


i 


i 


the  use  of  system  label  (PAGENO)  on  header  lines.  The 
contents  of  the  system  label  PAGENO  will  be  printed  at  the 
specified  position. 

when  using  system  labels,  sufficient  space  should  be 
allowed  on  the  line  for  the  entire  system  field  since  no 
overlap  is  permitted  between  specifications.  For  example: 
the  print  position  specified  for  the  system  label 
CLASSIF  can  never  be  less  than  32  since  the  length  of  this 
field  is  32  characters.  If  header  lines  are  conditioned, 
the  parameters  of  the  conditional  statement  cannot  be  file 
fields.  The  conditional  statement  must  be  the  first 
specification  for  tha*  line  if  the  output  of  the  entire  line 
is  to  be  conditioned. 

HEA  DERI  IF  PAGENO  LT  10 

HEADER  1 98  'INSERT  FOLLOWING  UNIT  CHANGES' 

This  example  would  condition  the  first  header  line  on 
the  basis  of  the  contents  of  the  system  label  PAGENO.  If 
the  page  number  were  less  than  10,  the  phrase 
INSERT  FOLLOWING  UNIT  CHANGES  would  be  printed.  The 
assumption  was  made  for  this  example  that  the  PAGENO  card 
had  a value  of  nine  and  therefore,  the  phrase  would  be 
printed  once  at  the  beginning  of  the  report. 

The  previous  example  illustrates  the  use  of  the 
conditional  statement  at  line  level  by  which  the  output  of 
the  entire  line  is  conditioned.  It  is  also  possible  to  have 
portions  of  lines  conditioned  as  well.  If  two  reports  were 
to  be  produced  from  one  RIT  and  the  header  line  for  each 
report  differed  on  the  basis  of  the  date  entered  at 
execution  tine,  they  night  be  specified  as  follows: 

HEADER1  85  'FISCAL  YEAR  1955*  IF  OPDATE  8/11  EQ  '1955' 

HEADER1  85  'FISCAL  YEAR  1964'  IF  OPDATE  8/11  EQ  '1964' 

The  specification  of  trailer  lines  follows  the  same 
rules  that  apply  to  header  line  specifications.  The  card 
type  is  TRAILER.  The  positioning  of  the  trailer  lines  is 
such  that  there  is  a blank  line  used  as  a separator  between 
the  last  body  line  and  the  first  trailer  line  or  as 
otherwise  specified  by  the  user  in  the  RIT.  The  user  nay 
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control  the  placement  of  the  trailer  lines  by  using  the 
SPACE  and  SP ACE. .. BEFORE  statements.  Thus  if  the  user  wants 
the  first  trailer  line  to  immediately  follow  the  last  data 
line  on  a page,  SPACE  1 BEFORE  TRAILERl  should  be  specified. 

3.2.10  Label  Lines  (LABELn) 

It  is  frequently  necessary  or  desirable  to  place  similar 
nondata  lines  in  the  body  of  the  report  containing  column 
identification  or  some  other  supplementary  information.  The 
general  form  for  these  label  line  specifications  is 
essentially  the  sane  as  those  for  header  lines. 

Co&di£i223l-State£2gt 

47  'ACTUAL  LABEL' 

LABELn  64  system  label 

75  literal 
80  SORT  4/7 

n is  the  label  level  number. 

All  of  the  discussion  of  header  lines  is  applicable  to 
label  lines  with  these  additional  specifications: 

The  parameters  of  the  conditional  statements  may  be 

file  fields. 

LABEL1  IF  CNAM  CHANCES 

LABEL1  14  'COUNTRY' 

This  example  would  cause  the  label  line  to  be  put  out 
only  if  the  data  field  called  CNAH  changed  from  a previous 
value. 

These  conditional  statements  can  also  be  used  in 
connection  with  individual  phrases  or  portions  of  the  line 
as  explained  with  header  specifications.  Care  should  be 
taken  when  using  the  conditional  statements  on  portions  of 
lines  because  if  all  portions  of  a line  were  conditioned  as 
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in  the  following  example  and  none  of  the  conditions  were 
satisfied,  a blank  line  would  result. 

LA BE LI  47  'COUNTRY'  IF  CNAH  CHANGES 

LAB  ELI  59  'NATO*  IF  CNAH  EQUALS  'FRANCE' 

LABEL1  90  'POSSESSED'  IF  POP  GE  9 

For  label  lines  associated  with  lines  containing 
periodic  data,  two  options  are  available,  if  the  label  line 
were  to  be  repeated  for  each  physical  line  containing  the 
periodic  subset (s)  until  the  end  of  the  set(s)  is  reached, 
the  specification  would  be  any  of  the  following: 

LABEL1  PERIODIC 

LABEL1  SET  (b) 

LABEI1  PER 

This  causes  the  label  to  print  whenever  sets  are  active 
(PER)  or  when  the  particular  set  (SET  (b) ) is  active. 

If  the  line  is  to  appear  only  once  prior  to  the  periodic 
line,  the  entry  PERIODIC  or  PER  would  be  oaitted. 

Both  line  conditional  statements  or  the  periodic 
statements  must  be  specified  before  the  specifications  for 
the  contents  of  the  label  line. 

Label  lines  must  be  associated  with  data  lines  so  that 
the  label  lines  appear  only  when  the  line  is  printed.  Each 
label  must  have  a level  number  of  one  to  three  digits,  and 
labels  and  data  lines  must  follow  one  numbering  sequence. 
A label  preceding  a data  line  and  having  the  same  number  as 
the  line  will  be  printed  only  when  the  line  is  printed. 

In  the  example: 


LA3EL1 


LINE1 


LINE  2 
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LABEL3  

LINE3  

LAdELl  and  LABEL3  would  be  printed  only  if  LINE1  and 
LINE3,  respectively,  were  printed.  It  is  not  necessary  that 
the  nueoering  sequence  be  concurrent,  only  that  it  be  in 
ascending  sequence. 

Two  or  aore  label  lines  say  be  associated  with  one  data 
line  by  adding  an  alphabetic  character  to  the  level  number. 

LABEL2A  17  • DATE' 

LABEL2B  19  'DAY  HO  YR' 

LINE2  19  DATEP 

The  previous  example  illustrates  two  label  lines  associated 
with  one  data  line  and  would  be  printed  as: 

DATE 

DAY  HO  YR 

30  10  64 

This  technique  say  be  used  only  with  body  label  lines 
(those  specified  by  LABEL)  and,  since  they  pertain  to  one 
data  line,  should  be  treated  logically  together.  Thus,  each 
set  of  label  lines  (those  with  the  alphabetic  level 
indication)  should  have  only  one  set  of  conditional 
statements  and  only  one  periodic  node  statement  even  though 
more  than  one  physical  line  is  involved.  To  indicate  that 
the  conditional  statements  or  periodic  statements  pertain  to 
all  the  labels  within  the  group,  the  specification  should  be 
given  as: 

LABEL2A  IF  .... 

LABZL2A  ..... 
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LABEL2B 

LINE2  

The  LABEL2A  condition  pertains  to  all  the  labels  tied  to 
the  next  line.  Label  lines  have  an  inherent  condition  in 
that  they  appear  only  when  their  associated  data  lines 
appear.  Thus,  any  conditional  statement  placed  on  label 
lines  is  subordinate  to  the  output  of  the  data  line.  OP 
checKS  the  body  lines  counter  automatically  to  see  that  all 
the  labels  and  at  least  one  occurrence  of  the  line  with  the 
same  line  number  can  be  printed  on  a page,  otherwise  OP 
ejects  to  a new  page. 

3.2.11  Data  Lines  (LlNBn) 

The  primary  emphasis  in  the  specification  of  a RIT  is 
the  display  of  file  fields  with  any  editing,  conversion, 
calculations,  totals,  or  counts  to  be  performed  on  the  data. 


£QflS.ent  s _o£_a_J2ala-itine 

The  contents  of  a line  may  be  either  fields  from  the 
data  record,  results  of  calculations,  literals  defined  at 
compilation  tine,  systen  labels,  self  defining  literals  or 
work  areas  passed  from  the  retriever. 

Literals  are  defined  as  being  either  alphameric  (bound 
by  quote  signs  and  up  to  52  characters  in  length),  binary, 
or  numeric.  A numeric  literal  may  be  either  signed  (♦  10) 
or  unsigned  (10).  Work  areas  passed  to  OP  by  the  retriever 
are  defined  by  set  association,  user  name,  output  length, 
and  modes. 

For  printed  reports,  these  specifications  are  given  on 
line  cards.  The  general  format  for  these  expressions  is 
similar  to  the  cards  previously  discussed.  These  specified 
lines  are  repeated  for  each  record  of  input  unless 
conditionally  excluded. 
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Line  Level  Conditional  Statement 
47  file  field 
LINEn  65  literal 

78  'ACTUAL  LABEL' 
action  statement 
n is  the  line  level  number. 

A line  level  number  may  be  any  1-  to  3-digit  number 
wnich  is  not  a duplicate  of  any  other  line  level  number. 

Duplicate  line  level  numbers  will  cause  assembler  errors. 

All  output  is  specified  by  indicating  the  lorn-order 
print  position  on  the  line,  followed  by  the  field  mnemonic, 
literal  name,  system  label  etc. 

LINEl  24  UNIT  ) 

LINEl  38  LOC 

It  should  be  noted  that  a line  specification  does  not 
necessarily  mean  one  physical  line  of  printing  per  record. 

If  periodic  data  is  specified,  many  lines  may  be  printed 
from  one  line  specification. 

Variaole  data  fields  are  indicated  by  specifying  the 
high-  and  low-order  print  position  on  the  line  followed  by 
the  field  mnemonic. 

LINEl  21-120  REFEP 
or 

LI NE 1 21/120  P.EFER 

One  hundred  characters  from  the  variable  field  REFEP 
will  De  printed  per  line  until  the  variable  field  is 
exhausted. 


ms  pa®  is  bbs?  quality  mmcA&Li 

IBOm  OQPY  PURKISHEO  lOHDC  - 
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Conditional  Statements  on  a Data  Line 

Data  line  specifications  may  be  conditioned  as  a whole 
or  nay  be  conditioned  by  portions. 

LINE1  IF  UNIT  CHANGES 


LINE1  24  UNIT 

The  above  example  demonstrates  the  conditioning  of  an 
entire  line.  Any  specifications  for  LINE1  that  follow  would 
print  only  if  the  file  field  UNIT  changes. 

LINE1  24  CNAH  IF  CN AH  CHANGES 


This  example  shows  the  conditioning  of  only  one  portion 
of  a line  (field  level  conditional).  The  data  contents  of 
the  field  CNAM  will  print  only  when  the  field  changes. 
Other  specifications  for  this  line  will  not  be  affected  by 
this  condition. 


LINS1  IF  CNAH  CHANGES 
LIN  El A 40  CNAM 
LI N SIB  40  MEQPT 


In  the  example,  if  CNAM  does  not 
nor  LINE1B  will  be  processed.  However 
be  processed.  Note  that  if  labels  are 
LINE1  or  tne  LINE1 A or  LTNE1B  they  are 
LI N El  condition. 


change  neither  LINF1A 
if  it  does,  both  will 
associated  with  the 
dependent  also  on  the 


LI N El  IF  ... 

LABEL1A  ... 
LIN  21  A ... 

LAB2L1B  ... 
LINE1B  ... 


Labels  and  lines  will  be  processed  or 
depending  on  the  LINEl  condition. 


not 


processed 
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3.3 


Specifications  fcr  Printed  Output 


The  following  sections  describe  extended  use  of  the 
processing  and  format  specifications  that  do  not  appear  in 
the  simple  output  format.  Specifications  for  punched  card 
and  aagnetic  tape  reports  are  described  in  sections  3.4  and 

3.5. 


3.3.1  Title  Lines  (TITLELINEn) 

The  specification  of  a TITLELINE  enables  the  user  to 
give  a title  to  the  report.  Title  lines  will  be  printed 
once  per  report  and  will  appear  at  the  beginning  immediately 
following  the  header  lines  and  lay  contain  the  sane  type  of 
information  as  the  header  lines. 


TITLELINE1  40  ‘THIS  REPORT  HAS' 
TITLELINE1  53  'COMPLETED  ON' 
TITLELINE2  50  OPDATE 

3.3.2  Format  Control  (SPACE,  EJECT,  SKIP) 


facing 

The  normal  spacing  for  a report  can  be  indicated  on  the 
FORMAT  card  as  previously  discussed.  This  spacing  should  be 
the  predominant  spacing  throughout  the  report.  Special 
spacing  to  replace  the  normal  spacing  or  for  special 
conditions  may  be  indicated  by  the  SPACE  card.  The  general 
format  of  the  SPACE  card  is: 

conditional  statement 

SPACE  n 

format  control  statement 

Normally,  the  conditional  statement  will  not  be 
necessary  and  the  spacing  action  will  be  specified  as: 

SPACE  5 
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ihis  spacing  will  override  the  normal  spacing  (specified 
on  FOattAT  card)  whenever  the  line  (label,  header,  title 
lin^s,  etc.)  preceding  this  SPACE  card  is  printed. 

The  conditional  statement  can  control  the  spacing  action 
as  in  the  following  example: 

LIMK1  

SPACE  2 

SPACE  5 I?  BEOP?  CHANGES 

LIME  2 

This  illustration  provides  for  double  spacinq  unless  the 
field  BEyp?  changes;  th^n,  ♦he  spacing  would  be  four  spaces. 

Format  control  statements  have  some  limitations.  If 
spacing  between  two  periodic  lines  is  desired  to  be 
different  from  spacing  of  different  subsets  of  the  same 
line,  a iauel  line  bus*  be  inserted  for  the  second  periodic 
line  and  spacinq  must  be  conditioned  on  the  printing  of  the 
laoei  line. 

The  following  specifications: 

LINE1 

SPACE  2 

SPACE  3 B EpOTE  LINE2 

LINE2 

would  cause  triple  spacing  between  the  printing  of  each 
subset  of  line  2 and  not  just  between  t.he  last  subset  with 
line  1 specifications  and  those  with  line  2. 

This  may  be  properly  handled  by: 

LXNE1 

SPACC  2 


I 
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SPACE  3 B^EOR*  LABEL2 

LAbE L l 

LINE  2 

SPACE  2 

It  spacing  is  desired  hpt»?»n  records,  another  format 
control  statement  is  used: 

SPACE  7 B ET«EPN  RECORDS 

This  type  of  spacing  expression  will  cause  the  specified 
spacing  to  take  place  only  between  each  data  record.  The 
specifications  aust  immediately  follow  the  last  data  line 
for  the  record.  Each  of  the  above  examples  could  be 
conditioned;  however,  if  the  action  is  conditioned,  the 
conditional  expression  must  be  placed  last. 

Whenever  a format  control  statement  includes  the 
conditional  I? . . . . . .COMPLETE , the  statement  must  include  the 

BETWEEN  RECORDS  modifier.  For  example: 

SPACE  3 BETWEEN  RECORDS  I*  CNAM  COMPLETE 


sJ,?£T_S'.dtemen* 


i.r.otner  method  of  controlling  the  format  of  a report  is 
the  JiCT  statement.  This  statement  will  cause  the  program 
to  vj;ct  to  a new  pag*  when  the  expression  is  encountered, 
printing  any  trailer  and  header  lines  before  proceeding  *o 
the  next  specification. 


t JECT 


conditional  statement 
forma*  control  statement 


nn  aoov“  examp]'’  illustrates  the  general  format  of  the 
EJECT  statement.  Tf  unconditional,  the  action  will  be  taken 
each  rime  tne  sta* en^nt  is  encountered.  The  conditional 
statement  can  b : usea  as  in  the  following  example. 


EJECT  IF  BODY LI  NFS  LT  5 
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Format  Control  Using  th  .Carriage  Control  .Tape_ /SKIP! 

In  addition  to  th^se  methods  of  controlling  the  format 
of  a report,  the  carriage  control  tape  on  th»  printer  may  bo 
used.  Tne  printer  may  b«  skipped  to  any  channel  on  the 
carriage  control  tape  with  the  use  of  the  SKIP  specification 
card.  The  card  has  th°  format: 


SKIP  TO  n 


format  control  statement 
conditional  statement 


The  n is  the  nu»b»r  of  tha  channel  to  which  the  printer 
will  skip.  This  action  takes  place  immediately  before  the 
next  line  card  is  printed.  Care  should  be  taken  when  using 
this  option,  since  the  body  lines  counter  is  not  decremented 
as  the  result  of  *he  skip  action.  The  body  lines  counter 
must  be  adjusted  through  the  PESET  card  if  the  format  is 
controlled  by  both  skip  and  spacing  action.  Also,  the 
carriage  tape  must  be  properly  punched. 

The  SKIP  specification  may  have  conditional  statements 
and  format  control  statements  as  previously  discussed  with 
the  SPACE  and  EJECT  specifications. 


3.3.3  Overflow  Line  Specifications  (OVEPFLOMn) 


The  OVERFLOW  operator  is  a feature  of  the  Output 
Processor  that  executes  when  body lines  have  been  exhausted 
for  the  previous  page  of  output.  The  OVERFLOW  block  serves 
a similar  function  as  a LIME  block,  however,  it  may  execute 


Wig 


'XHtoa*40*** 


04449 


J 
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only  at  the  beginning  of  a bodyline  section  after  an 
ovenlow  condition  has  occurred.  The  format  of  the  OVERFLOW 
statement  is: 


Conditional  Sfa*oaent 
47  file  field 

0V3FpL0Wn  47  literal 

47  System  label 
47  ‘actual  label* 

47  sortkey 
Action  statement 

An  OVERFLOW  level  number  may  be  any  1-  to  3-digit 
number.  A line  level  alphabetic  is  an  option  and  may  be 
used  to  control  multiple  lines  of  output  within  a level 
number . 

0V3F FLOW  blocks  are  automatically  conditioned  to  execute 
on  a page  which  has  been  reached  by  overflow  from  the 
previous  page,  cutout  may  be  further  conditioned  to  respond 
to  tne  full  range  of  tests  allowed  for  LIME  statements. 

References  to  data  file  fields/groups,  previously 
denned  literals,  system  labels,  self-defining  literals, 
sortxeys  and  action  statements  are  allowed  on  OVERFLOW 
lines. 

OV  EF  FLOW  blocks  will  not  function  if  one  of  the 

following  conditions  occur: 

a.  The  first  page  of  output 

d.  The  first  line  block  or  label  line  is  in  the 

process  of  executing  or  to  be  executed  when  an 
overflow  condition  has  been  reached 

c.  The  current  page  reached  by  the  process  of  the 

EJECT  format  control  operator. 

OVERFLOW  statements  appear  in  a FIT  before  the  first 
LINE  block  reference  and  after  the  last  HEADER  statement  or 
XI  Ti.  ELI  NS  statement.  Format  control  operators  (SPACE  and 
EJECT)  may  precede  or  follow  OVEPFLOH  statements,  however, 
caution  should  be  taken  wh*»n  the  EJECT  operator  is  used. 


ISIS  PAGE  IS  BEST  QUALITY  PRACTICABLE 
IRON  COPY  FURNISHED  TO  ODJi  — 
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s 


Y 


The  following  statements  (in  part)  are  ari  example  of  an 
OVERFLOW  application: 

nEADEBl  74  'FINANCIAL  PEPOPT' 

SPACE  5 

TITL5LINE1  fiO  • BUOGST  ACCOUNTING  BY  SERVICE* 

SPACE  5 

OVERFLOW  1 8 'SERVICE' 

OVERFLOW  1 14  SSPV 
OVERFLOW  1 26  • (CONTINUE!)  • 

SPACE  2 

LIN  El  IF  SEP V CHANGES 

J 

LINE  1 8 'SERVICE3' 

LINE1  14  SEPV 
SPACE  2 


In  the  previous  example  OVERFLOW1  will  be  ignored  for 
the  first  page  of  output  and  LINE  1 trill  execute  when  the 
first  record  is  processed  and  when  the  SEPV  field  value 
changes  in  records  that  follow.  When  an  overflow  condition 
is  sensed  OVERFLOVl  will  execute  at  the  beginning  of  the 
bodyline  section  of  the  new  page  if  LINE1  is  not  scheduled 
to  execute.  After  OVERFLOW  1 completes  it  execution  the  RIT 
will  continue  to  function  at  the  point  in  the  progran  where 
it  was  interrupted  when  the  overflow  condition  was  sensed. 


46 


OUTPUT  PROCESSOR  (OP) 


3.3.4  Definition  of  an  Area  (DEFINE) 

The  DEFINE  card  can  be  used  to  specify  the  length  of  an 
area  and  give  it  a name.  These  areas  are  useful  for:  (1) 
work  areas  for  computations,  (2)  result  areas  for 
computations  for  which  the  system-produced  lengths  are 
inadequate,  (3)  a literal  with  a specific  value  or  name  that 
might  be  used  repeatedly,  and  (4)  work  areas  passed  to  OP  by 
the  retriever. 

Additionally,  the  DEFINE  card  may  be  used  to  give  a name 
to  a repeatedly  used  edit  word,  to  an  array  literal  and  to 
a matrix  literal. 

DEFINE  WORK A 4 

, DEFINE  BUCKET  B 9 

DEFINE  TITLE  'THE  OUTPUT  SYSTEM  USE°S  MANUAL* 


The  first  example  will  cause  a work  area  of  four  diqits 
to  be  created  and  associated  with  the  term  WOP,KA.  It  will 
be  treated  as  a numeric  field  for  all  output  system 
functions. 

The  second  example  will  cause  a work  area  of  one  full 
binary  word  to  be  created.  This  work  area  would  be  used  for 
calculation  of  binary  data  fields.  The  8 specifies  the 
maximum  output  length. 

The  third  example  will  define  the  literal 
Id2  OUTPUT  SYSTEM  USERS  MANUAL  and  the  phrase  can  be 
referenced  with  the  term  TITLE.  Literals  defined  in  this 
manner  will  be  considered  alphameric.  Embedded  quotes  or 
ampersands  are  illegal. 

The  names  assigned  to  these  literals  can  be  any  name 
except  those  with  special  meaning  to  the  output  program. 


The  literals  defined  in  the  above  manner  will  be  treated 
as  fixed  fields.  They  can  he  associated  with  particular 
periodic  sets  or  as  periodic  literals  in  general  as  in  the 
following  examples: 
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DEFINE  SET  I APEAONS  4 
DEFINE  PERIODIC  TDY  * TD Y DATE* 
DEFINE  PER  STATUS  ' TDT* 


The  first,  example  defined  a 4-digit  work  area,  AREAONE, 
for  periodic  set  one.  '’’he  next  two  examples  are  two 
alternative  means  of  defining  TD Y and  STATUS  as  periodic 
literals.  A periodic  literal  for  a specific  set  will  be 
repeated  (it  specified  to  be  printed  on  a line)  until  the 
fields  in  the  set  have  been  exhausted.  A general  periodic 
literal  will  be  repeated  until  all  periodic  sets  specified 
on  tnat  line  are  exhausted. 

Note:  The  maximum  length  of  an  alphameric  literal  is  52 
characters.  The  maximum  length  of  a binary  literal  is  10 
characters.  The  maximum  length  of  a numeric  literal  is  999 
characters. 


The  maximum  output  length  of  a numeric  literal  output  by 
OP  is  15  bytes.  This  same  length  restriction  applies  to  the 
numeric  literals  used  in  arithmetic  operations.  Partial 
field  notation  may  be  used  to  address  and  output  portions  of 
numeric  literals  longer  than  15  characters. 

work  areas  containing  data  values  generated  by  the 
Retriever  FUNCTION  Operator  subroutines  are  available  to  the 
Output  Processor  for  display  or  further  processing.  These 
work  areas  are  referenced  by  a user-assigned  name.  There 
are  five  tullword  (4-byte)  work  areas  associated  with  each 
set.  The  system  labels  for  these  work  areas  are  WORK1 
through  HORK5.  Specification  of  these  areas  is  made  as 
follows: 

DEFINE  SET  n name  WOHKm  c t 


i 
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where 


DEPINE  - 

Identifies 

the 

stateaent 

SET  n - 

Ident if ies 
work  area 

the 

set 

number 

associated 

with  the 

naae 

User-assigned 

name 

for  reference  tc 

the  work 

area 

NOBKa  - 

Ident if ies 

the 

indiv idual 

work  area 

(HORK1 

through  WORK 5) 

c - Number  of  characters  to  be  output 

t - Type  cod»  which  identifies  the  node  of  data  in 

the  work  area  (A-alpha,  B-binary,  c-internal 
form  coordinate,  P-deciaal;  if  omitted,  the  mode 
is  assumed  to  te  binary) . 


Alpha  and  decimal  work  areas  can  be  one  to  four  bytes  in 
length.  It  less  than  four  is  required,  bytes  will  be  used 
starting  at  the  left  (high-order)  and  dropped  froa  the 
rightmost  (low-order)  side.  Coordinate  fields  can  be  fife 
six,  seven  or  eight  bytes  in  length,  corresponding  to  the 
standard  conversion  length  of  latitudes  and  logitudes  from 
internal  to  external  format. 

Reference  to  the  work  area  is  acroaplish«d  by  using  the 
naae  assigned  in  the  DEFINE  stateaent  as  shown  in  the 
following  exaaple: 

DEFINE  S FT  9 DIST  N OR K1  5 B 
LIN  51  50  DIST 

Assuae  the  retrieval  component  has  caused  a valu»  to  be 
generated  in  NOR K 1 for  set  9 (fixed  set).  The  DEFINE 
stateaent  assigns  the  naae  DIST  to  the  work  area  and 
specifies  the  area  contains  binary  data.  The  output  length 
is  specified  as  five  characters.  The  LIN  El  stateaent 
specifies  that  the  work  area,  referenced  by  the  naae  DIST, 
is  to  be  printed  in  position  50. 

The  user  should  note  that  work  areas  should  be  thought 
of  as  file  data  fields  in  teras  of  the  aanner  in  which  they 
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are  processed.  Hhen  they  are  associated  with  periodic  sets, 
values  are  passed  by  retrieval  only  for  flagged  (qualifying) 
subsets.  The  work  area  value  of  binary  zero  will  be  used  by 
OP  for  nonflaqged  subsets  when  the  rit  specifies  processing 
of  periodic  data  in  the  ALL  mode  (see  section  3.3.13). 
Specification  of  these  work  areas  should  not  be  Bade  in  RITs 
which  are  to  be  run  directly  against  a data  file,  since  no 
work  areas  will  exist. 

Defining  named  edit  Basks  within  a PIT  provides  the 
capability  to  repeatedly  use  the  edit  literal  on  output 
specifications  of  numeric  fields.  The  specification  of  a 
named  edit  aask  is  as  follows: 

DEFINE  EDIT  XXXX  'editmask* 


where 

DEFINE 

- identifies  the  statement 

type 

EDIT 

- is  the  keyword  parameter 
literal  as  an  edit  mask. 

designating  the 

xxxxxxx 

- the  user  designated  name 
(up  to  seven  characters) . 

for  the  edit  mask 

'editmask' 

- is  the  user  designated  edit  nask 

Reference  to  the  edit  eask  is  accomplished  by  using  the  name 
assigned  in  the  DEFINE  statement  when  printing  and  editing 
a numeric  field  as  in  the  following  example: 

DEFINE  EDIT  LEDIT  'bbbObb' 

LINE1  30  PERS  LEDIT 

The  number  of  replaceable  characters  within  defined  edit 
masks  must  be  equal  to  the  length  of  the  field  to  be  edited. 

Addressing  portions  of  fields  and  literals  is  discussed 
later  in  section  3.3.8.  An  alternative  to  partial  field 
notation,  which  say  be  used  when  referencing  nuneric 
literals,  is  referred  to  as  array  definition  and  processing. 
Basically,  an  array  is  defined  in  the  sane  Banner  as  a 
numeric  literal.  The  difference  is  that  there  is  a 
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reference  to  the  number  of  occurrences  or  repetitions  of  the 
literal.  An  array  is  considered  as  one  row  of  n columns  or 
occurrences.  Thus,  the  user  may  directly  or  indirectly, 
with  the  use  of  counters,  reference  any  segment  of  the  array 
by  its  occurrence  number.  The  definition  of  the  array 
literals  may  take  the  following  formats: 

DEFINE  LIT1  (X)  n 
DEFINE  LIT2  (X)  B n 

In  the  tirst  example,  the  array  I.IT1  is  defined  to  have 
X occurrences  with  the  length  of  each  occurrence  being  n. 
Each  of  those  occurrences  is  treated  as  a numeric  literal 
for  all  output  functions.  Note  the  parentheses  around  the 
occurrence  number;  they  must  be  present. 

The  second  example,  once  again,  has  X designating  the 
number  of  occurrences  of  length  n for  the  array  literal 
LIT2.  B defines  the  literal  as  being  binary  and  maintained 
as  binary  fullwords. 

Matrix  literals  are  used  in  conjunction  with  the 
elementary  matrix  capability  in  OP.  The  matrix  definition 
can  be  thought  of  as  an  advanced  array  in. that  a matrix  has 
all  of  the  characteristics  of  an  array.  As  previously 
stated,  an  array  consists  of  one  row  with  n columns  or 
occurrences.  A matrix  is  composed  of  one  or  more  rows  with 
n supportive  occurrences  or  columns,  with  arrays  it  was 
necessary  to  specify  only  the  number  of  columns.  With 
matrices  the  numbers  of  both  rows  and  columns  are  required. 
The  definition  of  a matrix  is  as  follows: 

DEFINE  MATA  (X,Y)  n 
DEFINE  MATB  (X,Y)  E n 

In  these  examples  X represents  the  number  of  rows  in  the 
matrix  while  Y represents  the  number  of  columns  or 
occurrences.  The  output  length  of  each  occurrence  is 
represented  by  n.  In  the  second  example  B designates  the 
matrix  occurrences  to  be  stored  internally  as  binary 
fullwords. 
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3.3.5  Storing  Data  for  Later  Use  (HOVE) 

The  HOVE  expression  is  used  to  transfer  data  either  fro* 
a data  record  to  a defined  area  of  the  RIT,  or  fro*  one 
defined  area  of  the  RIT  to  another  defined  area  of  the  RIT. 
Data  being  *oved  replaces  whatever  data  was  formerly 
contained  in  the  receiving  literal.  The  contents  of  the 
field  or  literal  being  moved  remain  unchanged. 

HOVE  aay  be  specified  as  a level  one  or  as  a level  two 
expression  and  has  the  following  general  foraat: 

HOVE  parameter  TO  literal 

The  parameter  *ay  be  a file  field/group,  a previously 
defined  literal,  a self-defined  literal,  an  array,  or  a 
■atrix.  The  literal  may  be  a previously  defined  literal, 
array,  or  Matrix. 

Subroutine  or  table  conversion  is  possible  for  a field 
or  literal  which  is  not  binary.  The  following  format  is 
used  for  subroutine/table  conversion: 

HOVE  parameter  SUBPT  submove  TO  literal 
HOVE  parameter  TABLE  tabname  TO  literal 

The  following  conventions  or  restrictions  apply  to  the 
use  of  the  HOVE  expression: 

a.  The  output  length  of  the  literal  must  be  the  same 
as  the  output  length  of  the  parameter  unless 
partial  field  notation  is  specified,  subroutine 
conversion  is  specified,  the  parameter  is  an  entire 
array  or  matrix,  or  the  parameter  is  a coordinate 
node  field. 

b.  Partial  field  notation  is  accepted  for  the 
parameter  and/or  the  literal  whenever  it  is  valid 
(see  section  3.3.8,  Addressing  Portions  of  fields). 
Mhen  used,  the  lengths  of  the  specified  portions  of 
the  parameter  and/or  the  literal  must  be  equal. 

c.  Subscript  notation  is  accepted  for  the  elements  of 
a matrix  or  an  array  (see  section  3.3.8,  Addressing 
Portions  of  fields). 
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d.  When  an  entire  natrix  is  specified  as  the  parameter 
(i.e.,  no  subscripts  are  provided  after  the  matrix 
nane) , the  literal  then  oust  also  be  an  entire 
aatrix.  The  elements  of  both  Matrixes  Must  have 
the  same  output  length,  and  the  total  nuaber  of 
eleaents  in  both  Matrixes  Must  be  the  same. 

e.  When  an  entire  array  is  specified  as  the  parameter 
(i.e.,  no  subscript  is  provided  after  the  array 
name) , the  literal  then  aust  also  be  an  entire 
array.  The  elements  of  both  arrays  Must  have  the 
saae  output  length,  and  the  number  of  occurrences 
in  both  arrays  must  be  the  saae. 

f.  When  subroutine  or  table  conversion  is  specified, 
the  length  of  the  literal,  or  the  length  of  that 
part  addressed  by  partial  field  notation,  aust  be 
egual  to  the  length  of  the  naxiaua  function. 

g.  A variable  field  or  set  say  not  be  specified  as  the 
parameter. 

h.  If  the  parameter  is  numeric  mode,  the  literal  aust 
also  be  nuaeric  Mode. 

3. 3. b Conditional  Exclusion  of  Data  Records  (OMIT) 

Data  records  nay  be  conditionally  excluded  froa  a report 
or  froa  one  of  the  output  aedia  with  the  use  of  the  OHIT 
specification.  This  statement  enables  the  user  to  be 
selective  in  the  processing  of  records  for  any  one  of  the 
specified  output  aedia,  or  both. 

The  production  of  an  index,  on  punched  cards,  is  an 
exaaple  of  its  application.  The  following  specif ications 
illustrate  the  aanner  in  which  a report  would  be  specified 
where  only  the  data  on  units  in  the  country  of  Germany  is  to 
be  included  in  the  printed  report,  and  an  index  of  the  pages 
where  each  location  began  is  to  be  punched. 

PILE  TBST360 

OHIT  IP  CN  AH  NOT  EQUAL  'GERMANY* 


POBHAT  PRINT 
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I 


PORHAT  PUNCH 

OHIT  IF  LOC  NOT  CHANGE 

CAR D1  30  LOC 

CARD1  78  PAGENO 


END 

The  OHIT  statements  in  the  previous  example  eliminate  the 
necessity  for  having  each  specification  conditioned  with  the 
sane  statement. 

The  correct  sequencing  of  these  statements  is  important 
when  they  are  used  to  select  data  records  for  processing. 
The  example  illustrates  the  case  where  only  one  file  is 
contained  in  the  report.  Hhen  used  in  this  instance,  the 
statements  placed  between  the  file  card  and  the  format  card 
pertain  to  all  formats;  the  statements  placed  after  a format 
card  pertain  only  to  that  format. 

If  conditioning  on  more  than  one  field  is  needed  to 
limit  the  number  or  type  of  records  to  be  processed,  then 
multiple  OHIT  statements  must  be  used  to  assure  expected 
results. 

OHIT  IF  SERV  NS  '.7* 

OHIT  IP  UU IN  NE  *00001'  AND  UUIN  NE  '00002' 

The  above  would  result  in  only  the  records  with  SERV 
equal  to  'J'  and  UUIN  equal  to  '00001'  or  '00002'  being 
processed.  All  others  would  be  omitted. 

Care  must  be  taken  in  the  meaning  of  the 

TOTAL  OP and  COUNT  OF statements  when  used  in 

conjunction  with  conditional  exclusion  of  data  records  from 
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a report  (the  OMIT  statement).  This  is  discussed  in  section 
3.3.17  NExpanded  Arithmetic  Operations. " 

3.3.7  Stopping  the  Report  Conditionally  (STOP) 

The  production  of  the  report  can  be  stopped  at  any  tine 
by  the  STOP  statement.  This  conditional  statement  should  be 
the  first  statement  following  the  FILE  card  for  the  file  to 
which  it  pertains. 

FILE  TEST360 

STOP  IF  CN AH  EQUALS  'ITALY' 


When  the  condition  is  satisfied,  the  report  is  terminated.  ' J 

In  the  previous  example  the  report  would  be  stopped  when  the 
country  was  ITALY.  The  record  which  contained  ITALY  would 
not  be  processed. 

Care  should  be  taken  that  this  specification  is  placed  in  > 

proper  sequence. 

FILE  TEST360 

FORMAT  PRINT  j 

FORMAT  PUNCH 

STOP  IF  CNAH  EQUALS  'ITALY' 

END 

If  this  statement  were  placed  as  shown  above,  the  record 
containing  ITALY  would  be  printed  and,  since  the  condition 
is  satisfied,  the  report  would  then  stop. 

1 
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3.3.8  Addressing  Portions  of  Fields  (Partial-field 
Notation) 

If  a portion  of  a field  or  literal  is  desired  for  output 
or  for  use  in  other  specifications,  the  portion  would  be 
indicated  as  follows: 

FIELDA  X/Y 

where  x is  the  high-order  and  y is  the  low-order  position  of 
the  field. 

This  notation  can  be  used  in  all  specifications  where 
previously  defined  literals  and  fields  are  referenced  with 
the  exception  that  a partial  field  cannot  be  specified  when 
a system  subroutine  (one  specified  in  the  FFT)  is  to  act  on 
that  field.  Partial  field  notation  is  not  allowed  on 
variable  fields  and  sets,  or  binary  literals  and  fields. 

LINE1  47  FIELDA  1/4 

LINE1  38  TOTAL  OF  FIELDB  5/6 

LI N El  80  FLDC  1-4  DIV  FLDD  5/9 


The  above  examples  illustrate  the  specification.  The 
partial  fields  are  treated  in  every  way  as  the  whole  field 
would  be  except  as  mentioned  above.  TKis  notation  has  a 
special  significance  when  printing  a RASP  answer  set,  and  is 
discussed  in  the  following  section. 

Another  means  of  addressing  portions  of  literals  is 
associated  with  the  use  of  array  and  matrix  literals (3.3.4) . 
Hith  these  types  of  literals,  subscripts  are  used  to  point 
to  particular  segments  or  sections  of  the  literal.  These 
subscripts  follow  the  user  supplied  literal  name  and  are 
enclosed  within  parentheses.  Subscripts  may  be  any  of  the 
following:  a self-defining  numeric  literal,  a previously 
defined  numeric  literal  or  a numeric  file  field.  In  the 
latter  two  cases,  it  is  the  content  of  the  field  thht  is 
actually  used  for  the  subscripting. 

An  array,  which  can  be  thought  of  as  one  row  of  n 
columns  or  occurrences  requires  a single  subscript 


OUTPUT  PHOCESSOP  (OP) 


designating  the  proper  occurrence  of  the  literal.  Matrixes 
are  composed  of  one  or  lore  rows  with  n columns  or 
occurrences  and  require  a pair  of  subscripts  that  designate 
the  row  and  coluan. 

Nnen  portions  cf  an  array  or  a matrix  are  desired  for 
output  or  for  use  in  other  specifications,  these  portions 
would  be  indicated  in  the  following  manner: 

AHRAY2  (5) 

ARRAY3  (CRT) 

MATRIX**  (2,5) 

MATRIX5  ( 3 , S0BS3 ) 


3.3.9  Addressing  the  PASF/QUIP  Sort  Key 

The  RASP  sort  key  is  variable  length  (a  function  of  the 
accumulated  length  of  fields  designed  by  the  user  for  sort 
requirements  in  the  RASP  query) . The  first  two  positions  of 
the  sort  key  contain  the  RASP  query  number  (QUERYNO) . The 
third  character  position  in  the  sort  key  is  not  used.  Sort 
key  position  4 contains  the  first  character  of  the  user 
desingated  sort. 

Two  procedures  have  been  provided  to  access  information 
in  the  sort  key  of  the  RASP  answer  records, 

a.  Partial  File  Notation 
LINE1  IF  SORT  5/10  CHANGES 

The  keyword  for  the  sort  key  is  SORT,  and  with 
the  use  of  the  partial  field  notation,  any 
position  of  the  user-designated  sort  can  be 
referenced.  Note,  however,  i.e.  the  user's 
responsibility  to  coordinate  the  specified 
sort  in  RASP  and  OP. 

b.  Named  Fields  of  the  Sort  key 


The  file  name  in  the  answer  record  can  be 
referenced  by  the  tern  FILENAME;  the  query 
number  by  the  tern  QUERYNO.  Either  of  these 
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two  names  can  be  used  in  the  same  way  as  file 
fields. 

The  QUIP  sort  key  is  similar  to  the  RASP  sort  key 
because  both  sort  keys  are  variable  length  and  are  a 
function  of  the  accumulated  length  of  fields  designated  by 
the  user  for  sort  requirements.  However,  the  QUIP  sort  key 
contains  no  query  number  or  leading  blank  positions, 
therefore,  sort  key  position  1 contains  the  first  character 
of  the  user  designated  sort. 

The  following  example  demonstrates  the  technique  for 
partial  field  notation  of  a QUIP  generated  sort  key. 

LINE1  IF  SORT  1/6  CHANGES 


3.3.10  Edit  Feature,  Subroutines,  and  Tables  (EDIT,  SUBRT, 

TABLE) 

Numeric  file  fields  can  be  edited  using  the  editing  ^ 

feature  or  converted  by  a conversion  table  or  subroutine. 

In  most  cases  these  edit  words,  tables,  or  subroutines  have 
been  specified  by  the  file  designer  in  the  Pile  Pormat  Table 
(PFT) . A field  name  (print  format  only)  with  no 

subroutine/table/edit  designation  will  default  to  the  output 
subroutine/table/edit  functions  specified  in  the  FPT.  A 
fieldname  followed  by  the  word  SUBRT,  TABLE,  or  EDIT  will  do 
the  same.  The  FFT  designation  can  be  overridden  by  the 
fieldname  followed  by  *#  (subroutine  or'  table)  or  ' • 

(quote,  quote  for  edit) . The  output  will  be  in  file  form  or 

it  can  be  overridden  by  #SUB/TAB#, 

SUBRT  SUBNAHE,  TABLE  TA8NAHE,  EDIT  'editword*,  or  the  name 
of  a defined  edit  word  (3.3.4)  and  the  data  will  be 

processed  using  the  designated  subroutine,  table,  or  edit 
word. 

Note:  Subroutines,  tables,  and  edits  are  not  automatic  on 

card  and  record  specifications. 
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Exaaple: 

LINE1  20  SER V ) Uses  subroutine  froa  FFT 

) 

LINE  1 20  SERV  SUBPT) 

LINE1  20  SERV  ••  Output  will  be  in  file  fora 

LINE1  20  SERV  «SUBXi  ) 

) Output  will  be  processed  by 
LINE1  20  SERV  SUBRT  SUBX)  subroutine  SUBX 

LINE2  30  PLDTG  ) Uses  edit  pattern  froa  FFT 

) 

LINE2  30  PLDTG  EDIT) 

LINE2  30  PLDTB  • • Overrides  PFT  edit  and  output 

data  in  file  fora 

LINE2  30  PLDTB  NAHEDIT  Override  FFT  edit  and 

uses  defined  edit  word 
N AH  EDIT 

LINE2  30  PLDTB  Overrides  FFT  edit  and 

specifies  edit  pattern 
to  be  used 

When  directly  specifying  the  edit  pattern  to  be  used  on  a 
field,  as  in  the  last  two  exaaples  above,  care  aust  be  taken 
to  ensure  that  any  nonreplaceabl e characters  to  be  inserted 
are  accounted  for  when  print  positions  are  designated. 


The  following  instructions  will  aove  a portion  of  a table 
function  to  print: 

DEFINE  LIT1  • (size  literal  to  aaxiaun  length 

of  function.) 

LINE3  HOVE  RADTG  SUBRT  DTGOS  TO  LTT1 
LINE3  16  LIT1  3/5 

If  RADTG  eguals  680307,  07HAR68  would  be  aoved  to  LIT1  and 
LINE3  position  16  would  contain  HAR,  thus  rearranging  a date 
field  to  aake  it  aore  readable  at  output  tiae. 


> 
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Note:  If  there  is  an  unsuccessful  return  from  a user  table 

or  subroutine,  the  argument  will  be  output  by  OP. 

The  following  instructions  will  move  a portion  of  a data 
field  to  a work  area  for  subsequent  editing. 

DEFINE  HORKA  6 

LINE1  MOVE  TRDTG  1/2  TO  HORKA  5-6 
LINE1  MOVE  TRDTG  3/6  TO  HORKA  1-4 
LINE1  15  HORKA  EDIT  • **!-«»- )t)S' 

IF  TRDTG  equals  651215, 

this  procedure  would  print  12-15-65. 

The  logic  tight  be  extended  in  this  way: 

LINE1  9 'DEC*  IF  HORKA  1/2  EQ  '12' 

LINE1  15  HORKA  3/6  EDIT 

and  the  printout  would  be  DEC  15,65. 

Note:  Editing  nay  be  done  only  or  numeric  file  fields  or 

literals. 

Note:  Binary  values  cannot  be  passed  through  a TABLE.  The 

results  will  be  either  the  printing  of  blanks  or  meaningless 
characters.  The  following  logic  will  accomplish  the  task 
successfully: 

DEFINE  MUHFLD  2 

LINE1  MOVE  BINFLD  TO  NUMFLD 

LINE1  10  NUMFLD  TAELE  BINARY 

3.3.11  Literals  on  Data  Lines 

Literals  can  also  be  specified  on  a line  by  the  use  of 
a bounded  label  (by  quote  signs)  or  by  a label  that  has 
previously  defined  a literal. 

LINE1  47  'ACTUAL  LABEL' 

or 


LINE1  50  LIT1 


I 
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In  the  latter  example,  the  term  LIT1  has  been  previously  ^ 

defined  with  a DEPINE  card. 

then  a literal  and  periodic  data  are  to  be  printed  on 
the  line,  the  literal  will  be  treated  as  fixed  in  that  it 

Mill  appear  only  on  th®  first  physical  line.  If,  however,  j 

the  literal  is  desired  on  every  physical  line  containing  J 

periodic  data  until  the  periodic  set(s)  is  exhausted,  then  j 

the  specification  would  be: 

LINE1  47  'DAY  HO  YR'  PERIODIC 

or 

LINE1  47  'DAY  HO  YR'  PER 


It  is  also  possible  to  tie  the  literal  to  any  particular 
set  so  that  the  literal  will  be  repeated  only  until  that  set 
is  exhausted  by  specifying  as  in  the  following  exawple: 

LIN  El  47  'DAY  MO  YR • SET  n • 

n is  the  periodic  set  ID. 

Referencing  array  literals  for  output  purposes  is  done 
by  using  the  literal  name  followed  by  a subscript  enclosed 
within  parentheses.  These  subscripts  nay  be  a specific 

nuweric  literal  value,  the  contents  of  a previously  defined  1 

nuneric  literal  or  the  contents  of  a naaed  numeric  file 
field.  This  can  be  shown  by  the  following: 

LI NE 10  30  LIT1  (2) 

LINE10  59  LIT2  (SCRIPT) 

LINE20  40  LIT2  (PERS)  , 

where  SCRIPT  is  a previously  defined  nuaeric  literal  and 
PERS  is  a nuaeric  field  froa  a data  file. 

i 

then  referencing  the  matrix  literal  for  output  purposes, 
the  user  aust  specify  what  portions  of  the  matrix  he  wishes  i 

to  output  and  where  he  wants  the  output  in  his  formatted 
output  line.  To  do  this,  the  matrix  literal  name  aust  be 
specified  at  an  output  position  along  with  a set  of 
subscripts,  within  parentheses,  representing  the  desired  row 
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and  column.  These  subscripts,  as  vith  arrays,  may  be 
numeric  literals,  the  names  of  previously  defined  numeric 
literals,  or  named  numeric  file  fields.  The  following  are 
examples: 

LI  HE  1 0 20  HATA  (1,5) 

LINE10  40  HATA  (2,S0B2) 

LINB10  60  HATB  (SUB3,8) 

LIN  E10  80  NATB  (9,PERS) 

It  should  be  noted  that  when  using  previously  defined 
literals  or  file  fields  it  is  the  contents  of  these  fields 
that  determines  the  appropriate  row  or  column. 

In  order  to  reduce  the  number  of  specifications  required 
to  output  a matrix,  a second  method  is  available.  It  allows 
specification  of  each  low-order  output  location  chosen  for 
the  matrix  literal  on  the  output  statement.  In  previous 
discussions  of  subscripting,  subscripts  represented  one  row 
and  one  column,  thereby  directing  OP  to  a particular  segment 
of  a matrix.  However,  utilizing  subscripts  in  association 
with  multiple  print  positions,  a start  column  and  a stop 
column  are  specified  in  conjunction  with  a row  or  else  a 
start  row  in  conjunction  with  a column.  The  following  are 
examples: 

LINB10  20  40  60  HATA  (X-Y,Z) 

LINE20  20  40  60  NATB  (A,  B-C) 

The  first  example  shows  that,  starting  with  row  X and 
stopping  with  row  T,  the  values  found  in  column  Z are  to  be 
printed  in  positions  20,  40,  and  60.  Giving  the  symbols  X, 
Y and  Z values  of  1,  3,  and  6 respectively,  the  following 
will  be  printed:  in  position  20,  row  1,  column  6;  in 
position  40,  row  2,  column  6;  and  in  position  60,  row  3, 
column  6. 

In  the  second  example  of  multiple  print  position  vith 
matrices,  the  values  in  row  A from  column  B through  column 
C will  be  printed  in  the  specified  positions. 

When  using  the  start  and  stop  subscript,  the  number  of 
rows  of  columns  may  not  exceed  the  number  of  print  positions 
without  generating  an  error  diagnostic.  This  method  of 

i 


62 


1 

! 

i 

i 


OUTPUT  PROCESSOR  (OP) 


matrix  output  specification  reduces  the  number  ' of  OP 
statements  required  to  output  the  matrix. 

3.3.12  Periodic  Information  (SCAN , ALL,  FIRST,  LAST,  SET) 

No  node  specification  is  necessary  if  the  periodic  mode 
(SCAN)  for  the  report  is  to  remain  the  same  throughout. 
(This  is  essentially  for  a report  received  from  RASP.)  If, 
however,  the  node  desired  differs  or  is  not  consistent 
within  a RIT,  then  the  node  can  be  specified  on  each  line. 
Specif ication  for  each  line  containing  periodic  information 
to  be  printed  in  the  SCAN  node  may  be  as  follows: 

LINE1  SCAN 

LINE2  SCAN  SET  n where  n is  the  set  ID. 


The  first  of  the  two  examples  states  that  all  periodic 
sets  are  to  be  printed  in  the  SCAN  mode  for  every 
reiteration  of  LINE1  (flagged  subsets  only).  The  second 
example  can  be  used  to  tie  the  mode  to  a particular  periodic 
set.  If  this  were  done,  the  specified  set  would  be  printed 
with  that  node  while  the  rest  of  the  periodic  sets  would  be 
printed  with  the  normal  file  mode. 

If  a mode  is  not  specified  at  structure  time,  SCAN  is 
assumed. 

To  specify  that  the  LAST  n or  the  FIRST  n subsets  are  to 
be  printed  the  statements  are: 

LINE1  FIRST  5 

LINE2  LAST  10 

LINE3  FIRST  5 SET  5 

LINE3  LAST  10  SET  6 


The  first  example  causes  only  the  first  five  subsets  of 
each  periodic  set  to  be  processed  while  printing  line  1. 
The  second  example  causes  the  last  10  subsets  of  each  set  to 
be  processed  for  line  2.  The  last  two  examples  tie  the 
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specifications  to  specific  periodic  sets.  These 

specifications  override  any  assigned  node. 

If  the  node  for  retrieval  specified  for  a periodic  set 
is  other  than  SCAN  and  ail  subsets  are  wanted  in  the  report, 
the  specifications  would  be: 

LINE1  ALL 
or 

LINE1  ALL  SET  n 


The  first  exanple  will  cause  all  subsets  to  be  printed 
for  all  periodic  sets  specified  on  the  line.  The  second 
exanple  ties  the  specification  to  a periodic  set.  This 
specification  is  not  necessary  when  printing  a report 
directly  fron  the  file,  in  which  case  all  subsets  are 
printed. 

The  periodic  node  specified  in  this  nanner  will  affect 
the  output  in  this  line  only.  Thus,  if  fields  fron  the  sane 
periodic  set  were  placed  on  two  lines,  each  line  would  have 
to  have  the  node  specified.  There  is  no  need  to  keep  the 
node  for  a set  consistent  throughout  the  report. 

with  periodic  infornation  it  is  often  required  or 
preferred  to  have  the  sane  field  (or  fields)  fron  nore  than 
one  subset  printed  on  a line.  This  is  done  by  specifying 
each  low-order  output  location  chosen  for  that  field  on  the 
line. 

LINE1  10  20  30  FIELD 

The  above  exanple  would  place  the  specified  field  fron  three 
subsets  on  line  1 in  the  positions  indicated.  The  line 
would  be  repeated  in  this  node  until  the  set  was  exhausted. 
If  nore  than  one  field  fron  a subset  is  specified,  it  is 
inportant  that  all  fields  fron  the  sane  set  be  specified  in 
the  sane  way;  that  is,  if  nore  than  one  subset  per  line  is 
indicated  for  a field,  the  specification  for  another  field 
in  the  sane  set  nust  be  the  sane. 


-1  ' 
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There  are  two  eain  ways  in  which  fields  fron  the  saee 
periodic  set  can  be  displayed  on  lore  than  one  line.  The 
first  would  be  on  the  basis  that  each  line  is  repeated  until 
the  set  is  exhausted  and  then  the  next  line  is  repeated 
until  the  set  is  exhausted.  if  a periodic  set  contains 
fields.  A,  B,  c,  and  D,  the  specifications  eight  appear  as: 

LINE1  10  PLOA 

LINE1  20  PLDB 

LINE1  30  PLDC 

LINE2  10  PLDD 

The  foraat  would  appear  as: 

Subset  1 A B C 


2 

3 

1 

2 

3 


A 

A 

D 

D 

D 


B 

B 


C 

C 


It  Bight  be  desirable  to  display  the  above  set  in  the 
following  Banner: 


A 

D 

A 

D 

A 

D 


B 


Since  the  lines  can  be  considered  as  one  group,  this  pattern 
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i 


i 

* 


i 

i 

* 


Mould  be  specified  as  follows: 

LIN21A  10  FLDA 
LINE1A  20  PLDB 
LINE1A  30  PL  DC 
LINE1B  10  PLDD 

The  only  aode  limitation  that  must  be  placed  on  this  method  of 
specifying  periodic  sets  is  that  the  aode  for  each  set  and  the 
nuaber  of  subsets  per  line  aust  be  the  saae  in  each  line. 

If  a periodic  aode  is  specified  for  a series  of  lines 
containing  periodic  information  from  the  saae  set,  it 
would  be  specified  as  follows: 

LINE1  SCAN 

LINE1A  10  FLDA  J 

LINE1A  20  PLDB 
LINE1A  30  PL DC 
LINE!*  10  PLDD 


> 


Note:  Befer  to  conditional  statements  in  section  3.2.8  for 

further  restrictions. 

3.3.13  Associated  Label  Lines 

Each  line  in  a group  of  lines  nay  have  associated 
labels,  or  the  entire  group  of  lines  aay  have  one  or  more 
labels  associated  with  it. 

LABEL1A  47  CLASSIP 

LABEL1B  50  • ACT DAL  LABEL* 

LINE1B  10  PLDA 
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LINE1B  20  FDLB 
LINB1C  30  PLDC 

In  the  above  example,  the  label  lines  1A  and  IB  ace 
associated  with  the  first  data  line  (LINE1B)  that  follows. 
The  level  sequence  given  in  this  exaeple  follows  the  rule 
which  states  that  when  proceeding  froe  a label  line  with  an 
alphabetic  level  to  a data  line  (LINE)  with  an  alphabetic 
level,  the  level  of  the  data  line  must  be  the  sane  as  or 
greater  than  the  preceding  label  line. 

LABEL1A  PERIODIC 

LABEL1A  26  CLASSIP 

LINE1A  


LAB2L1B  PERIODIC 
LIME1B  


This  exaeple  illustrates  a group  of  lines  which  has 
label  lines  associated  with  each  line.  Note  that  since  the 
labels  are  to  be  repeated  with  the  data  lines  each  tine  they 
are  printed,  they  have  been  specified  as  periodic. 

Each  of  the  label  lines  or  groups  of  label  lines  eay  be 
conditioned  provided  that  the  conditional  statement  appears 
as  the  first  specification  for  a Series  of  contiguous  label 
lines  (the  first  alpha  label  line  of  a group).  The  output 
of  these  lines  can  be  conditioned  with  the  use  of  the 
conditional  statements  described  previously. 

The  only  restriction  placed  upon  line  level  conditional 
statements  (those  which  condition  the  output  of  the  entire 
line)  is  with  periodic  lines.  A periodic  line  containing 
more  than  one  subset  per  line  cannot  be  conditioned  on  a 
field  from  a periodic  set.  Also,  as  a general  rule,  lines 
with  alphabetic  level  indication  (LINE1B)  should  not  be 
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conditioned.  If  alpha  labels  and  lines  are  used,  the  only 
specifications  which  should  be  placed  on  nonalpha  lines 
(LINE1)  are  line  level  conditions  and  action  expressions. 
No  print  specifications  should  be  used  on  nonalpha  lines 
when  the  nixed  node  (alpha  and  nonalpha  statenents  in  a 
block)  is  used. 


3.3.14  Variable  Infornation 

variable  infornation  such  as  renarks  nust  be 
in  this  fornat: 


indicated 


LIHE1  8/100  REFER 

This  specification  provides  for  data  fron  a variable  set 
or  variable  field  to  be  printed  fron  position  8 through  100. 
The  infornation  will  be  repeated  in  this  fornat  until 
exhausted. 

No  conditioning  is  pernitted  at.  level  4 of  a line,  card, 
or  record  statenent  specifying  variable  data.  However,  the 
statenent  nay  be  conditioned  at  level  2,  for  exanple: 

LINE1  IF  VS27  GT  0 
LINE1  8/100  REFER 

Note:  Partial-field  notation  nay  not  be  used  on  variable 
infornation. 


Note:  Variable  sets  nay  not  be  referenced  in  the  BREAKLINE 
section. 

3.3.15  Action  Statenents  (TOTAL,  COUNT,  ADD,  SUB,  NUL, 
DIV,  RESET) 

Sinple  totals  and  counts  of  data  fields  can  be  specified 
on  line  cards  as  follows: 

LINE1  50  TOTAL  OF  HEORC 

LINE1  60  COUNT  OF  HEQPT 

The  two  exanples  above  would  print  the  total  nunber  of 
ready  eguipnent  (right-justified)  and  the  count  of  the 
eguipnent  ID. 
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These  statements  specify  the  result  of  the  action,  not 
the  perforaance  of  it.  The  total  or  count  would  be  one 

which  had  accuaulated  since  the  beginning  of  the  report  or 
since  its  last  printing.  This  would  be  a total  or  count  by 
record  unless  conditional  printing  is  specified.  The  actual 
totaling  or  counting  cannot  be  conditioned,  only  the 
printing.  Totals  and  counts  are  cleared  when  printed. 

TOTAL  OF  accuaulates  a sum  for  the  occurrences  of  a 
fixed  numeric  or  of  a periodic  numeric  field  belonging  to 
sets  that  have  been  flagged.  COUNT  OF  tallies  the 

occurrences  of  a fixed-length  field,  either  fixed  or 

periodic.  Variable-length  fields  and  variable-length  sets 
(VSETS)  nay  not  be  counted. 

Simple  calculations  can  be  specified  by: 

LINE2  100  Factor,  Operator,  Factor,  Operator, 

Factor,  etc.  This  might  look  like: 

LINE2  100  Field  PLUS  Field  MINUS  Literal 

The  calculation  would  be  performed  left  to  right  and  the 
result  will  be  printed  in  position  100.  The  factors  nay  be 
field  names,  numeric  literals,  or  a literal  that  has 

previously  been  defined.  The  operators  that  can  be  used 
are: 

Aldilifin  SublEactififl  fliillLfilis&iiga  Siiision 

ADD  SUB  HUL  DIV 

PLUS  MINUS 

♦ (12  punch)  -(11  punch)  *(11-4-8  punch)  / (0-1  punch) 

or 

(12-6-8  punch) 

The  results  of  totals,  counts,  or  calculations  can  be 
conditionally  printed  on  a line  by  the  use  of  conditional 
statements. 

LINE1  50  COUNT  OF  HEQPT  IF  CN AM  EQ  • GERMANY • 

LINE1  60  NEPSD  MINUS  HEORC  IF  MEPSD  3E  MEORC 
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The  doors  examples  will  cause  the  count  of  HEQPT  to  be 
printed  for  each  record  for  the  country  of  Geraany  and  the 
nuaber  not  ready  (H2PSD  MINGS  HEORC)  if  the  nuaber  possessed 
is  greater  than  the  nuaber  ready. 

The  results  of  totals,  counts,  or  calculations  of  this 
type  can  also  be  edited  or  be  acted  upon  by  a subroutine  or 
taole. 

LI NE1  80  TOTAL  OF  SEAUTH  EDIT  'J>bb,bbb' 

This  exaaple  would  cause  the  result  of  the  totaling  of 
SEAUTH  to  be  edited  with  the  edit  word  provided. 

£2i£utaii2&s_wittL.!lit2£ais 

Another  aethod  of  specifying  additions  or  subtractions 
to  or  froa  predefined  literals  is  by  the  following: 

LINE1  ADD  paraaeter  TO  literal 

LINE1  SUB  paraaeter  PROH  literal 

The  paraaeter  aay  be  nuaeric  fields  or  nuaeric  literals. 
The  literal  aust  be  either  a systea  label  or  a nuaeric  area 
which  has  been  previously  defined.  These  stateaents  can  be 
conditioned.  Note,  that  like  the  HOVE,  when  the  calculation 
is  designated  on  a LINE,  care  aust  be  exerted  to  avoid  the 
printing  of  blank  lines.  The  ADD  and  SUB  stateaents  aay  be 
specified  as  separate  stateaents  siailar  to  the  HOVE  when  it 
is  not  necessary  or  convenient  to  perfora  these  functions  on 
a line. 

££S£1 

The  RESET  card  can  be  used  to  reset  any  arithaetic 
result  area  or  nuaeric  literal  to  a particular  value.  It 
aay  be  placed  anywhere  in  the  specifications.  The  general 
fornat  of  the  card  is: 

RESET  area  conditional  stateaent 


RESET  area  TO  conditional  stateaent 
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The  first  statenent  is  used  when  resetting  a nuaeric 
literal  (up  to  999  characters  in  length)  to  zero.  The 
second  stateaent  will  reset  the  area  to  the  value  specified. 
The  resultant  area  will  have  true  sign  and  leading  zeros. 
The  reset  stateaent  nay  also  be  used  on  a LIME  card  or 
RECORD  card.  Additionally*  the  RESET  stateaent  nay  be  used 
in  conjunction  with  array  and  aatriz  literals.  These 
literals  are  described  in  section  3.J.4.  In  these 
instances,  the  basic  concepts  reaain  the  saae  with  the  use 
of  subscripts  providing  the  only  difference. 

The  following  RESET  stateaents  are  appropriate  for 
arrays: 

RESET  LIT1 
RESET  LIT1  TO  5 
RESET  LIT1  (2) 

RESET  LIT  1 (SCRIPT)  TO  4 

The  first  stateaent  above  would  reset  all  occurrences  of  the 
defined  array  literal,  LIT1,  to  zero,  and  the  second  would 
reset  all  occurrences  of  the  literal  to  5.  The  third 
stateaeat  would  reset  the  second  occurrence  of  LIT1  to  zero, 
and  the  fourth  would  reset  the  occurrence  of  LIT1  designated 
by  the  contents  of  the  literal  SCRIPT  to  4. 

The  neans  of  restoring  aatrix  literals  to  an  initial 
value  is  siailar  to  that  used  with  arrays  except  that 
aatrizes  require  two  subscripts  to  designate  a row  and  a 
colunn.  The  following  show  how  restoration  or 

reinitilization  is  designated: 

RESET  MATA 
RESET  MATA  TO  5 
RESET  HATA  (1,5) 

RESET  HATA  (1,3)  TO  4 

The  first  ezaaple  resets  the  entire  natrix  (each  aenber 
of  each  row  and  coluan)  to  zero  while  the  second  resets  each 
aeaber  of  the  aatrix  to  5.  The  third  and  fourth  exaaples 
show  resetting  with  the  aid  of  subscripts.  The  third 
exanple  illustrates  the  aeaber  at  row  1,  coluan  5 being 
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reset  to  zero.  The  fourth  exaeple  resets  the  eeeber 
represeuted  by  row  1 and  coluen  3 to  4. 

The  RESET  card  is  useful  when  resetting  nueeric  systea 
labels. 

RESET  BODYLINES  TO  10 

RESET  PAGENO 

The  first  eiaeple  will  reset  the  body  line  counter  to 
ten,  while  the  second  exawple  will  reset  the  page  counter  to 
zero.  The  ability  to  reset  these  systee  constants  allows 
■ore  flexibility  of  fornat  control  under  the  control  of  user 
data.  For  instance,  the  page  number  could  be  reset  to  a 
value,  based  upon  a change  in  a control  field,  to  produce 
separate  voluaes  of  a report. 

Since  the  page  counter  is  incremented  after  the  trailer 
lines  are  printed,  the  location  of  the  page  nuaber  will 
determine  when  and  to  what  value  the  systea  label  PAGENO  is 
to  be  reset. 

Eaas_Mi6aj;_2fl_H£aiai:_Lis£_ 

The  systea  constant  PAGENO  should  be  reset  to  one  less 
than  the  desired  value  and,  if  an  EJECT  statement  is  present 
with  the  saae  condition,  placed  on  the  line  preceding  the 
EJECT  card. 

FORNAT  

HEADER1,  47,  PAGENO 

LIME1  

LINEl  RESET  PAGENO  IF  SFRV  CHANGES  AND  SERF  EQ  •¥• 

EJECT  IF  SENT  CHANGES  AND  SERV  EQ  1 F* 


TRAILERI 
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ggqe  Euaber  op  Trailer  Line 

PAGENO  should  be  reset  to  the  desired  value  and  placed 
after  at  least  one  data  line  specification. 

F0RH1T  

HEADER  1 

LIN El  

RESET  PAGENO  TO  1 IF  SERV  CHANGES  AND  SERF  £Q  *F* 

LINE5  

EJECT  BETHEEN  RECORDS  IF  SERV  COMPLETE 
TRAILER1  47  PAGENO 

flsagfc-aa&aitflfli-A£aa-££2&-£g»Btttati2as 

Results  of  calculations,  totals,  and  counts  nay  be  reset. 
FORMAT  

LINE1  COMPUTE  TOTLMIL  EQ  TOTAL  OF  HEPSD  IF  MECLQ 
EQ  *C* 

LINE2  IF  SERV  COMPLETE 
LINE2  47  TOTLMIL 
LINE2  RESET  TOTLMIL 


The  exaaple  illustrates  how  the  total  of  class  C equipment 
possessed  eight  be  specified. 

in  these  exaaples,  the  conditional  statement  IF 

COMPLETE  has  been  used.  The  use  of  this  expression  is 
discussed  in  this  section  under  the  heading  "Suaaary 
Reports. ” 
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3.3.16  Result  Areas  (Standard  Lengths) 

Arithmetic  operations  may  be  performed  on  integer  values 
that  appear  in  the  fore  of  self-defining  literals,  defined 
work  areas,  data  file  fields  or  OP  defined  literals. 
Arithnetic  operations  include  action  expressions  (TOTAL  and 
COUNT) , simple  calculations  (ADD  1 to  HORKX)  and  expanded 
arithmetic  operations  (COMPUTE  HORKZ  EQ  1 ♦ HORKZ) . The 

result  of  each  arithnetic  operation  is  stored  in  a work 
space  whose  length  has  been  calculated  by  OP  based  on  the 
length  of  the  factors  involved  in  the  calculation.  The 
standard  length  of  the  result  area  is  determined  as  follows: 

TOTAL  Twice  the  length  of  the  field  being  totaled 

COUNT  Six  digits 

COMPUTE  Addition  - length  of  longest  factor  plus  one 

Subtraction  - length  of  longest  factor  plus 
one 

Multiplication  - sun  of  the  lengths  of  the  two 
factors 

Division  - equal  to  the  length  of  the 

dividend. 

Examples  of  result  lengths  calculated  by  OP: 

(a)  LINE  1 40  TOTAL  OP  PERS 

In  this  example  PERS  is  a 6-character  numeric  file 
field.  The  result  of  the  totaling  operation  will 
be  stored  in  a 12-character  OP  defined  area  and 
printed  on  a line  with  the  right-most  character  in 
position  40. 

(b)  LINE1  40  COUNT  OP  SER? 

In  this  example  SERf  is  a 1-character  alpha  field. 
A count  of  all  records  that  contain  this  field  will 
be  performed  and  the  result  of  the  count  will  be 
stored  in  a 6-character  OP  defined  result  area  and 
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printed  on  a line  with  the  right-aost  character  in 
position  40. 

(C)  LINE  1 50  WORK A ♦ HORKB  ♦ HORKC 

In  this  exanple  HORKA  has  a defined  length  of  3 
characters;  HORKB  has  a defined  length  of  7;  and 
HORKC  has  a defined  length  of  5.  The  result  area 
calculated  by  OP  will  be  the  length  of  the  longest 
factor  plus  one,  i.e.  8 characters.  The  result 
will  be  printed  on  a line  with  the  right-aost 
character  on  position  50. 

(Note:  In  the  previous  exaaples,  the  OP  defined  work  areas 
will  be  initially  set  to  zero  prior  to  arithaetic 
processing.  The  work  areas  will  be  restored  to  zero  when 
results  are  published.) 

(d)  LINE1  COMPOTE  HORKX  EQ  PERS  * 100  / HORKA 

In  this  exanple  the  length  of  the  result  area, 
HORKX,  will  be  calculated  by  OP  based  on  the  length 
of  factors  and  use  of  arithaetic  operators  in  the 
arithaetic  expression.  Calculation  of  factors  in 
an  arithaetic  expression  is  perforaed  by  pairs  of 
factors  froa  left  to  right  (no  parenthetical 
expressions  peraitted) . The  file  field  PERS 
(length  6 characters)  is  aulti plied  by  the  self- 
defining literal  100  (length  3 characters).  The 
coabined  length  of  the  two  factors  creates  an 
interia  result  area  of  9 characters.  HORKA  is  a 
previously  defined  work  area  with  a length  of  7 
characters  and  is  the  divisor  in  divide  expression 
in  which  the  9-character  interia  work  area  is  the 
dividend.  The  guotient  or  result  of  the  divide 
operation  will  be  stored  in  a work  space  the  length 
of  the  dividend  (9  characters) . The  result  area, 
HORKX,  has  not  been  explicitly  defined  in  this 
exaaple.  Result  areas  for  COMPUTE  stateaents  nay 
be  iaplicitly  expressed  or  explicitly  defined,  i.e. 
DtPIHB  HORKX  9.  A warning  nessage  will  be  issued 
it  the  coapile  phase  if  the  defined  work  area's 
length  does  not  correspond  with  the  OP  calculated 
reselt  area  length.  If  the  OP  calculated  work 
■»ace  is  longer  than  the  user  defined  result  work 
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space  significant  characters  of  the  result  will  be 
truncated  when  the  result  is  noved  to  the  user 
define  work  space. 

(Note:  Result  space  in  a COMPUTE  expression  is  initially  set 
to  zero,  however,  it  is  not  restored  to  zero  when  published. 

The  user  nay  use  the  RESET  operator  to  restore  work  areas  if 
desired) . 

The  results  of  all  arithmetic  expressions  will  be 

printed  with  leading  zeroes  suppressed  and  without  sign 
notation  unless  an  EDIT  aask  has  been  specified  to  process 
the  results.  Arithmetic  processing  is  performed  on  integer 
values  only.  Resulting  fractions  from  a divide  process  will  - 
not  be  saved  for  output  or  subsequent  arithmetic  processing. 

The  factors  and  results  associated  with  all  arithmetic 

I calculations  should  not  exceed  15  numeric  digits. 

3.3.17  Expanded  Arithmetic  Operations  (TOTAL,  COUNT,  COMPUTE) 

In  cases  where  the  results  of  totals,  counts,  and  J 

computations  are  required,  or  where  the  actions  of  the 

arithmetic  statement  rather  than  the  output  of  the  result 
must  be  conditioned,  another  form  of  arithmetic  is  required. 

The  three  methods  are:  expansion  of  the  TOTAL  or 

COUNT  OP statement,  the  COMPUTE  statement,  and  the 

COMPUTE  card. 


This  form  allows  the  user  to  specify  totals  and  counts 
in  the  manner  discussed  in  section  3.3.16  but  in  addition, 
the  result  may  be  saved  for  further  reference. 

The  next  example  illustrates  the  method  by  which  a total 
and  count  can  be  made  and  their  results  divided  to  produce 
an  average.  This  average  is  then  printed  in  position  30. 
Notice  the  absence  of  print  positions  in  the  first  two 
statenents;  output  locations  could  be  included  if  the  total 
and  count  were  to  be  printed. 

LINE1  TOTAL  OP  PERS  IN  TOTAPER 


LIME1  COUNT  OP  UIC  IN  CNTUIC 
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LINE1  30  TOTAPER  DI7  CNTUIC 

The  internal  procedure  for  the  previous  example  would  be 
to  total  the  authorized  personnel  field  and  aove  the  results 
to  TOTAPER,  count  the  UICs  and  aove  the  results  to  CNTUIC, 
and  then  perform  the  division.  The  internal  totaling  and 
counting  accumulation  areas  will  be  reset  to  zero  after  the 
■ove  has  been  performed  (on  each  record) . 

The  areas  specified  for  the  results  can  be  defined  as 
work  areas  with  define  cards. 

DEFINE  TOTAPER  2 

DEFINE  CNTUIC  4 

These  areas,  if  not  defined  in  the  above  Banner,  will  be 
defined  by  the  output  system  using  the  standard  lengths,  as 
shown  under  "Result  Areas,"  section  3.3.16. 

These  statements  specify  the  results  of  the  operation 
rather  than  the  action  of  it.  Totals  and  counts  specified 
in  the  method  mentioned  here  occur  before  the  processing  of 
the  first  format  specification.  The  use  of  OMIT  statements 
can  therefore  affect  the  totaling  and  counting  operations. 

If  the  OMIT  statement  is  placed  following  the  FILE  card 
but  before  the  FORMAT  card,  the  total  or  count  will  take 
place  on  all  records  that  have  not  been  omitted. 

If  the  OMIT  statement  is  placed  after  a FORMAT 
statement,  the  total  or  count  will  take  place  on  all  records 
regardless  of  the  conditions  specified  in  the  OMIT 
ex pression. 

Another  specification  which  will  affect  these  operations 
is  the  periodic  mode  specification  for  a line.  The  total  or 
count  will  occur  on  all  records  according  to  the  periodic 
mode  indicated  for  the  line  which  contains  the  total  or 
count  specification. 
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sflflgm.am«B3Bt 

The  COMPUTE  statement  fora  of  arithaetic  operations  can 
be  used  in  cases  where  the  coaputed  results  are  needed  for 
later  use,  for  unusual  accuaulation  of  totals  and  counts, 
and  where  the  perforaance  of  the  action  aust  be  conditioned. 

The  general  fora  for  a total  and  count  is: 

LINExx  COMPUTE  result  area  EQ  TOTAL  OF 

LINExx  COMPOTE  result  area  EQ  COUNT  OP 

These  stateaents  would  cause  the  total  or  count  action 
to  be  performed  every  tine  the  line  is  printed.  The  result 
will  be  placed  in  the  area  designated  by  the  literal  naae. 
The  next  tine  that  the  total  or  count  is  Bade,  the  value 
will  be  added  to  the  result  area  (TOTAL)  or  the  result  area 
will  be  increased  by  one  (COUNT)  . 

The  resultant  area  nay  be  defined  as  a work  area  with  a 
DEFINE  card  or  the  user  can  allow  the  area  to  be  defined  by 
the  systen  using  the  standard  lengths. 

The  general  fora  for  confutations  is: 

LINExx  COMPUTE  result  area  EQ  factor,  operator,  factor, 

operator,  etc. 

The  factors  can  be  either  field  nanes,  previously 
defined  literals,  or  nuneric  literals. 

The  conputation  proceeds  fron  left  to  right  with  integer 
arithaetic.  Thus,  the  factors  night  have  to  be  scaled  to 
provide  the  desired  accuracy. 

Any  of  the  above  nethods  of  specifying  arithaetic 
operations  nay  be  made  conditional  by  the  use  of  the 
conditional  stateaents  previously  described.  This  will 
cause  the  action  rather  than  the  output  of  the  result  to  be 
conditioned. 
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The  COMPUTE  card  is  needed  for  those  cases  where  it  is 
not  possible  or  convenient  to  put  the  COMPUTE  statement  on 
a line,  card,  or  record  specification.  It  could  be  used  if 
soae  calculation  were  performed  on  a data  record  and  the 
record  conditionally  included  in  the  report  based  upon  the 
results  of  the  coeputation.  Suppose  one  wished  to  include 
all  units  that  possess  aore  than  five  types  of  equipnent. 
The  specifications  to  accoaplish  this  would  be: 

FILE  TEST360 

COMPUTE  CNTEQP  EQ  COUNT  OF  HEQPT 

OMIT  IF  CNTEQP  LT  6 

HEQPT  saaes  are  contained  as  subsets  in  Periodic  Set  1. 
The  COMPUTE  stateaent  would  count  the  nuaber  of  types  of 
equipaent  (i.e.,  subsets)  and  place  the  count  in  CNTEQP. 
This  literal  could  have  been  defined  with  a DEFINE  card; 
however,  if  not  previously  defined,  the  literal  will  be 
defined  using  the  standard  lengths. 

Caution  should  be  exercised  when  using  the  COMPUTE  card 
with  periodic  data  since  the  entire  set  is  processed  using 
the  COMPUTE  stateaent  before  the  next  specification  is  acted 
upon. 

COMPUTE  EQPRDT  EQ  MEORC  PLUS  MEORN 

This  stateaent  adds  the  two  categories  of  ready 
equipaent  and  would  result  in  the  literal  EQPRDT  containing 
the  result  froa  the  coaputation  on  only  the  last  subset. 

The  COMPUTE  card  is  also  used  in  conjunction  with  the 
generation  of  aatrixes  prior  to  their  being  output.  it  is 
froa  this  level  1 card  type  that  the  rows  and  coluans  for 
the  specified  aatrix  are  deterained  providing  COUNTS  and 
SUMs  of  the  fields.  The  FOR/AND  logical  connectors  are  used 
siailarly  as  they  are  used  for  QUIP  aatrix  generation  with 
the  exception  that  table  and  subroutine  conversion  of 
paraaeter  values  is  not  peraitted.  Literal  values  serving 
as  paraaeters  aust  appear  in  the  FOR/AND  stateaent  as  they 
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appear  in  the  file.  The  basic  statements  for  matrix 
processing  are  written  in  the  following  manner: 

COMPUTE  MATA  EQ  COUNT  OF  UNIT  X 

COMPUTE  FOB  SERV  EQ  'N*  • J' 

COMPUTE  MATA  EQ  SUM  OF  FERS  X 

COMPUTE  FOP  SERV  EQ  *W'  »N'  X 

COMPUTE  AND  »C  EQ  'PARIS*  'LONDON' 

The  above  examples  show  how  the  COMPUTE  card  provides 
both  one-  and  two-dimensional  matrices.  (It  should  be  noted 
that  following  the  POR/AND  logical  connectors  any  of  the 
accepted  OP  relational  operators,  except  ABSENT  and 
CONTAINS,  may  be  used  to  qualify  the  data  for  the  SUMs  and 
COUNTS.)  The  first  example  designates  one-dimensional 
matrix  with  three  columns  while  the  second  represents  a two- 
dimensional  matrix  with  two  columns  and  two  rows.  Both 
matrices  MATA  and  HATB  must  have  been  previously  defined. 
The  COMPUTE  statement  will  not  cause  automatic  generation  of 
matrix  literals. 

An  asterisk  may  be  used  as  one  of  the  operands  in  the 
literal  string,  and  when  so  used,  it  takes  on  special 
significance.  It  provides  a universal  natch  condition  and 
causes  processing  of  an  appropriate  work  area  for  all  data 
elements  not  associated  with  an  area  specifically  designated 
by  the  list  of  literals. 

3.3.18  Summary  Reports  (IF  COMPLETE) 

Summary  information  is  desired  in  many  cases  not  only 
involving  the  entire  report,  but  also  on  portions  of  a 
report.  Under  normal  circumstances,  actions  conditioned  on 
the  presence  of  a change  in  a field  are  processed  with  the 
data  from  the  new  record  present.  This  is  desirable 
whenever  an  action  on  data  from  a record  is  conditioned  on 
a change  from  the  previous  record. 

LIN  El  IF  CNAN  CHANGES 

LINE1  47  CHAM 

The  field  CRAM  from  the  new  record  would  print  when 
CN AM  changed. 
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For  sunnary  inforaation  applications,  it  is  desirable  to 
condition  the  action  on  the  basis  that  a certain  type  field 
or  record  is  complete.  An  exanple  would  be  to  total  the 
nunber  of  pieces  of  equipment,  possessed  for  a certain  class. 
The  result  would  be  placed  on  a separate  line  before  the 
data  froa  the  new  record  is  printed  (beginning  with  LINE1 
specifications) . This  is,  in  essence,  a change  in  the 
field,  but  the  action  desired  is  different. 

The  following  exanple  assunes  that  a request  fron  the 
TEST360  file  is  ordered  by  CNTRY  and  that  the  total  nunber 
of  weapons  located  by  country  is  wanted  in  the  report. 

LINE2  COMPUTE  NOMRD  Y EQ  NEORC  PLUS  MEORN 

LINE2  ADO  NUMRDY  TO  TOTRDY 

LIHE2  50  NUMRDY  6/7  EDIT  »| M' 

LINE3  IF  CNTRY  COMPLETE 

LINE3  60  TOTRDY  6/8  EDIT 

LINE 3 RESET  TOTRDY 


In  this  illustration,  the  two  ready  categories  are  added 
together  and  the  result  is  added  to  a literal  t.o  achieve  a 
running  total  of  the  nunbers  of  readies.  Then,  when  the 
country  is  conplete,  line  3 will  be  printed  containing  this 
total.  The  literal  is  then  reset  to  zero  to  prepare  for 
sinilar  operations  in  subsequent  countries.  Line  3 will  be 
printed  each  tine  a change  occurs  in  the  CNTRY  field  before 
any  lines  containing  inforaation  about  the  next  country  are 
printed.  The  line  will  also  be  printed  at  the  end  of  the 
report. 

Any  specifications  that  can  be  placed  on  a nornal  line 

nay  be  placed  on  IE  COMPLETE  lines,  except  that  neither 

periodic  set  fields  nor  periodics  nay  be  referenced  within 
a conditional  expression.  Sinilarly,  variable  sets  nay  not 
be  referenced  in  the  BRBAKLINE  section.  All  data  fields 
referenced  will  be  fron  the  last  record,  rather  than  the 
record  in  which  the  change  occurred.  Periodic  fields  or 
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literals  referenced  will  be  only  from  the  last  subset  in  the 
last  record. 

Note  that  the  specification  differs  from  the 

IP CHANGES  conditional  statement  in  that,  the  latter 

would  cause  printing  of  a line  on  the  first  occurrence  of  a 

country  while  the  IP COMPLETE  statement  would  cause 

printing  after  the  last  occurrence. 

IP COMPLETE  conditionals  may  also  be  specified  at 

field  or  action  level;  but  only  if  the  line  on  which  it 

occurs  is  also  conditioned  by  an  IF COMPLETE.  Consider 

the  case  of  personnel  totals  by  location,  country  and  geo- 
political area.  One  nay  obtain  totals  by  the  various 
subdivisions  in  the  following  manner: 

LINE3  IF  LOC  COMPLETE 


LINE3 

9 • 

TOTAL 

FOR 

t 

LINE3 

20 

LOC 

LINE3 

26 

TOTAL 

OP 

PERS 

LINE3 

30 

CNTRY 

IF 

CNTRY  IS  COMPLETE 

LINE3 

36 

TOTAL 

0F 

PERS  IF  CNTRY  COMPLETE 

LINE3 

40 

GEPOL 

IF 

GEPOL  COMPLETE 

LINE3 

46 

TOTAL 

OF 

PERS  IF  GEPOL  COMPLETE 

The  above  line  would  be  printed  as  follows  if  only  LOC 
changed: 

TOTAL  FOB  PENTAGON  25026 

If  both  country  and  location  changed,  the  line  would  be: 

TOTAL  FOB  PENTAGON  25026  UNITED  STATES  9612436 
and  if  location,  country  and  geopolitical  area  changed: 
TOTAL  FOR  PENTAGON  25026  UNITED  STATES  9612436 
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NORTH  AMERICA  190013245 

Whenever  a format  control  statement  includes  the 

conditional  IP COMPLETE,  the  statement  must  also  include 

BETWEEN  RECORDS.  For  example: 

SPACE  3 BETWEEN  RECORDS  IP  CN AM  COMPLETE 

The  calculation  of  periodic  values  in  conjunction  with 
IF  COMPLETE  logic  is  not  accepted  in  NIPS  360  FFS.  It  was 
accepted  in  NIPS  1410  FFS  but  not  supported.  RITs  trying  to 
use  this  logic  will  not  structure  and  must  be  rewritten. 

An  example  of  this  illegaj  statement  is: 

LINE4  IF  SORT  4/4  COMPLETE 
LINE4  ADD  PERFLD  TO  PERLIT 

where  PERFLD  is  a field  from  a periodic  set  and  PERLIT  is  a 
previously  defined  numeric  literal  (fixed  or  periodic). 

Note:  IF  COMPLETE  lines  may  not  be  intermingled  with  other 
line  specifications  not  intended  to  have  IF  COMPLETE  logic 
applied.  The  first  encounter  of  an  IF  COMPLETE  line  sets 
the  mode  for  all  other  line  specifications  and  action 
statements  within  that  format. 

3.3.19  Final  Lines  (FIN ALLINEn) 

It  is  possible  to  specify  final  lines  that  will  be 
printed  only  at  the  conclusion  of  the  report.  These  lines 
cannot  contain  data  from  a record  unless  it  has  been  stored 
in  a literal  at  sone  previous  time.  The  normal  use  for  this 
type  of  line  would  be  for  such  operations  as  totals  and 
counts  or  other  types  of  summary  data.  After  the  last 
record  has  been  processed,  any  final  lines  will  be  printed 
and  then  the  trailer  lines  will  be  printed. 

FINALLINE1  10  'TOTAL* 

FIN ALLINE1  17  TOTAL  OF  PERS 

The  above  specifications  would  place  the  total  of  all 
authorized  personnel  for  all  processed  records  into  position 
17  preceded  by  the  word  TOTAL.  The  conditioning  of  these 
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lines  follows  the  sane  restrictions  as  header  lines  in  that 
the  parameter  of  the  conditional  statement  cannot  be  a file 
field.  Note:  Summary  information  a ay  be  obtained  on 

portions  of  the  report. 

3.3.20  EXTRACT  Statement 

While  processing  data  records  from  one  file,  it  may  be 
desirable  to  retrieve  data  values  from  a second  file 

(Interfile  Output) . This  nay  be  done  through  the  use  of  the 
EXTRACT  statement.  This  statement  nay  only  be  specified 

within  the  first  file  of  a multifile  PIT.  The  first  file 

will  be  known  as  the  primary  file,  while  other  referenced 
files  are  secondary. 

The  general  form  of  the  EXTRACT  statement  is  as  follows: 

FIELD  NAME 

SORTKEY  SUBPT 

EXTRACT  LITERAL  TABLE  FILE  NAPE  IE... 

IFOGRPn  m/n 

In  the  above  examples  of  statement  syntax,  "FIELD  NAME” 
is  any  field  specified  in  the  FFT  of  the  primary  file,  the 
file  containing  pointers  or  Pecord  IDs  for  secondary  files. 
The  "SORTKEY"  is  the  result  of  ordering  the  RASP  answer  set, 
while  a "LITERAL"  is  any  defined  alpha  or  numeric  literal. 

"IFOGRPn”  is  a special  case  of  a group  name  within  the 
FFT  of  the  primary  file  where  n is  any  alphanumeric 
character.  This  field  was  designed  especially  for  the 
Interfile  Output  capability.  Fields  designated  as  IFOGRPn 
must  have  at  least  two  fields.  The  first  contains  the  name 
of  a secondary  file  or  an  indicator  code  which  is  converted 
to  the  secondary  file  name  by  a subroutine  or  table 
specified  in  the  FFT  and  the  second  contains  a pointer  to 
the  desired  data  record  or  group  of  records  in  the  secondary 
file. 


As  shown,  subroutine  conversion  and  partial  field 
notation  may  be  used  on  the  EXTRACT  statement.  The 
exception  to  this  is  IFOGRPn  which  may  not  make  use  of  these 
functions.  The  two  required  fields  of  IFOGRPn  nay  have 
subroutine  conversion  specified  in  the  FPT . Unlike  the 
manner  in  which  other  groups  are  processed,  automatic 
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conversion  of  these  fields  will  take  place  when  IPOGRPn  is 
referenced  on  the  EXTRACT  statement. 

On  all  forns  of  the  EXTRACT  statement,  a file  name  is 
required  except  when  IFOGRPn  is  used.  The  file  name  is 
required  to  show  the  secondary  file  from  which  data  is 
requested.  As  was  previously  stated,  the  first  field  of  the 
IFOGRPn  must  contain  a file  identifier.  If  a file  name 
should  be  referenced  when  specifying  IFOGRPn,  the  EXTRACT 
operation  will  take  place  only  when  the  file  identified  by 
the  first  field  of  the  group  matches  the  file  name  specified 
on  the  EXTRACT  statement. 

The  file  name  specified  on  the  EXTRACT  statement,  and 
the  file  identifier  in  the  first  field  of  the  IFOGRPn  is  a 
maximum  of  seven  characters  in  length.  The  DD  statements 
which  correspond  to  the  secondary  files  being  referenced  may 
contain  a qualified  data  set  name  up  to  44  characters  in 
length.  The  last  segment  of  the  qualified  data  set  name 
must  match  the  file  name  designated  on  the  EXTRACT 
statement.  J 


The  standard  OP  conditional  statement  may  be  used  to 
determine  when  the  EXTRACT  statement  should  be  executed. 

When  the  EXTRACT  statement  is  encountered  in  RIT, 
processing  of  the  primary  file  is  interrupted  and  the  field 
specified  is  used  as  the  key  for  record  retrieval  from  the 
secondary  file. 

Example: 

EXTRACT  UIC  FILEZ  IF  UIC  NE  • • . 

In  the  above  example,  if  the  condition  is  net,  the 
contents  of  the  field  UIC  will  be  used  as  a Record  ID  in 
FILEZ.  Hhen  a data  record  is  found  with  that  key,  the  data 
record  is  processed  by  the  specifications  written  for  FILEZ 
and  control  is  returned  to  the  statement  following  the 
EXTRACT  statement  in  the  primary  file  specifications.  If  no 
record  is  found,  control  returns  immediately  to  the  primary 
file  processing. 


Several  data  records  might  be  retrieved  by  using  a field 
that  is  shorter  in  length  than  the  key  length  of  the 
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secondary  file.  Assuming  the  Record  ID  of  the  secondary 
file  is  six  characters  in  length  and  using  the  following: 

DEFINE  BUCKET  ' * a 6-character  alpha  literal 

MOVE  UIC  TO  BUCKET 

EXTRACT  BUCKET  1/1  FILEC  IP  UIC  1/1  EQ  *J' 

All  records  with  a record  key  beginning  with  a 'J*  will  be 
retrieved  from  FILEC  and  processed.  When  a field  specified 
on  the  EXTRACT  statement  is  longer  than  the  Record  ID  of  the 
secondary  file,  it  will  be  truncated  to  the  secondary  file 
key  length. 

Data  fields  containing  record  keys  to  secondary  files 
nay  be  from  the  fixed  or  periodic  sets.  (They  nay  not  be 
variable.)  When  operating  with  periodic  sets  in  the  primary 
file,  OP  will  operate  in  the  "ALL"  node  for  SOURCE  DIRECT 
and  in  the  "SCAN"  node  for  SOURCE  RETRIEVAL  runs.  Periodics 
from  the  secondary  files  are  always  in  the  "ALL"  node. 

The  processing  of  periodic  fields  on  the  EXTRACT 
statement  will  occur  as  follows.  The  first  subset  will  be 
accessed  to  obtain  a record  key.  Once  found,  the  data 
record (s)  is  processed  by  the  secondary  file  RIT 
specifications.  when  the  data  record (s)  have  been 
completely  processed,  control  is  returned  to  the  primary 
file  where  the  second  subset  is  accessed.  When  all  subsets 
of  the  primary  file  have  been  exhausted,  processing  of  the 
primary  file  continues  with  the  next  RIT  specif ication. 

A Report  Instruction  Table  that  contains  an  EXTRACT 
operator  nay  be  executed  in  Source  Direct  node.  In  this 
case  the  input  data  sets  to  OP  are  primary  and  secondary 
file.  The  primary  file  nay  be  sequentially  or  index 
sequentially  organized.  The  secondary  file(s)  must  be  index 
sequentially  organized.  Specifications  for  the  primary  and 
secondary  files  follow  the  rules  for  merged  file  RITs 
discussed  in  section  5.1.3  and  5.1.4  with  the  following 
exception.  The  primary  file  can  be  designed  as  one  of  the 
secondary  files,  when  processing  one  record  in  the  primary 
file,  the  user  can  extract  data  from  other  records  in  the 
primary  file.  The  primary  file  must  have  the  first  set  of 
RIT  specifications  for  primary  processing  and  another  set  of 
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specifications  that  will  be  invoked  only  in  response  to  an 
EXTRACT  statement. 

The  RIT  with  the  EXTRACT  operator  may  also  be  excuted  in 
Source  Retrieval  mode.  The  input  to  OP  will  be  an  answer 
(QRT/QDF)  produced  by  RASP.  The  input  to  RASP  should  be 
specified  as  the  primary  file  in  the  RIT.  As  wit,;.  Source 
Direct,  the  primary  file  may  also  be  designated  as  a 
secondary  file  for  use  with  EXTRACT. 

The  QRT/QDF  can  be  from  a single  file  or  merged  file 
retrieval.  In  either  case  the  user  should  exercise  caution 
in  addressing  the  SORTKEY  in  secondary  file  specifications 
as  result  of  an  EXTRACT  statement  with  an  IF  COMPLETE 
condition.  Only  the  current  SORTKEY  (the  one  following  the 

one  on  which  the  IF  COMPLETE  condition  was  met)  is  available 
to  the  secondary  file  specifications.  This  is  not  the  same 
SORTKEY  the  system  saved  for  use  in  the  breakline  (IF 
COMPLETE)  block  for  the  primary  file.  If  this  presents  a 
problem,  SORTKEY  data  should  be  moved  to  user  specified 
literals  ahead  of  the  EXTRACT  statement.  i 

Use  of  EXTRACT  with  a merged  file  retrieval  requires  an 
understanding  of  how  the  system  functions.  Each  QRT  record 
(SORTKEY)  is  flagged  with  the  name  of  the  file  from  which  it 
was  retrieved.  These  flags  indicate  which  primary  or 
secondary  set  of  RIT  specifications  will  process  the  QRT/QDF 
record.  Since  EXTRACT  statements  are  permitted  only  in  the 
primary  file  specifications,  they  will  only  be  executed  when 
a QRT  record  pointing  to  the  primary  file  is  encountered. 

A QRT  record  pointing  to  a secondary  file  will  bypass  the 
primary  file  specifications  and  execute  the  appropriate 
secondary  file  specifications  using  the  QRT/QDF  records  as 
input.  If  the  same  secondary  file  is  referred  to  in  an 
EXTRACT  statement,  the  same  secondary  file  specifications 
will  be  executed  with  the  record (s)  specified  in  the  EXTRACT 
statement  from  the  secondary  data  file  itself,  not  the 
QRT/QDF,  as  input.  The  secondary  file  specifications  must 
be  designed  to  properly  process  either  input.  When  an 
EXTRACT  statement  calls  for  the  secondary  file  with  the  sane 
name  as  the  primary  file,  the  second  set  of  specif ications 
with  that  file  name  will  be  executed  with  the  record  (s)  from 
the  data  file  as  input.  Only  the  QRT  record  (SORTKEY) 
pointing  to  the  primary  file  is  available  to  secondary  file 
processing  in  response  to  an  EXTRACT  statement. 
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3.3.21  GOTO  Statement 

A aeans  of  altering  the  order  of  RIT  execution  is 
provided  through  the  use  of  the  GOTO  stateaent  and  its 
associated  TAGn  stateaent  (n  is  a 1-  to  4-digit  number) . 
Normally,  OP  operates  in  a line-by-line  manner  as  it 
processes  each  data  record.  The  GOTO  statement  enables  the 
OP  user  to  control  the  order  of  execution  of  the  RIT. 

Essentially,  the  GOTO  statement  provides  the  user  with 
a aeans  of  branching.  The  general  fora  of  the  statement  is 
as  follows: 

GOTO  TAGn  [IF..  . ] 

GOTO  NEXT  RECORD  [IF...] 

TAGn 

In  the  above,  TAGn  is  the  label  to  which  control  should 
be  passed.  The  use  of  the  if  conditional  stateaent  is 
optional.  The  "GOTO  NEXT  RECORD"  statement  is  a special 
usage  of  the  GOTO  statement.  When  this  statement  is 
encountered,  processing  of  the  current  data  record  is 
terminated  and  the  next  data  record  available  for  processing 
is  obtained.  This  statement,  therefore,  allows  the  user  to 
exit  from  the  RIT  without  executing  additional  RIT 
specifications. 

The  GOTO  statement  is  allowed  in  all  sections  of  an  RIT 
where  LINES  may  appear.  This  means  that  it  may  not  appear 
between  HEADERS,  TRAILERS,  OVERFLOWS,  etc.  There  are  other 
restrictions.  A GOTO  may  not  be  placed  within  a LINE  block. 
A GOTO  may  not  branch  between  formats  in  a multiformat  FIT, 
nor  may  it  branch  between  files  in  multifile  runs.  Within 
a single  format,  a GOTO  may  not  traverse  the  boundaries 
between  regular  RIT  specifications  and  those  within  the 
breaklines  (IF  COMPLETE)  section. 

3.3.22  PERFORM  Statement 

Similar  to  the  GOTO  statement,  the  PERFORM  statement 
enables  the  RIT  to  branch  cn  command  to  a single  LINE,  CARD 
or  RECORD,  to  execute  the  sane,  and  return  to  the  next 
sequential  OP  statement  following  the  PERFORM. 
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The  execution  of  the  PERFORM  statement  may  be 
conditioned  using  the  standard  OP  conditional  statement.  It 
is  allowed  in  the  standard  RIT  area,  that  is,  in  those 
sections  where  LINEs  may  appear.  The  execution  of  this 
branching  capability  is  not  allowed  across  the  boundaries 
between  regular  RIT  specifications  and  those  within  the 
breaklines  (IF  COMPLETE)  section,  nor  is  it  allowed  between 
files  of  a multifile  RIT  or  between  formats  of  a multi- 
format  RIT. 

The  following  are  examples  of  the  PERFORM  statement: 

PERFORM  LINEX 

PERFORM  LINEX  IF... 

In  the  above,  LINEX  is  the  operand  of  the  PERFORM 
statement,  and  it  designates  the  particular  LINE,  CARD  or 
RECORD  to  be  executed  or  performed.  IF  is  the  standard  OP 
conditional  statement  and  its  usage  is  optional.  The 
PERFORM  statement,  like  GO^O,  provides  the  user  with  a means 
of  branching.  The  main  differences  are  that  the  PERFORM 
returns  and  it  refers  only  to  individual  LINEs,  CARDs  and 
RECORDS. 

3.3.23  Self-Defining  Literals 

A self-defining  literal  consists  of  one  to  52  characters 
enclosed  by  apostrophes.  All  letters,  decimal  digits  and 
special  characters,  except  single  quotes,  nay  be  used  in  the 
literal.  Following  examples  demonstrate  the  use  of  self- 
defining literals. 

HEADER1  79  ****ANN0AL  REPORT  - 1974***' 

LINE3  120  •$• 

DEFINE  LIT  1 'JUNE  66  JULY* 

NOTE:  In  the  last  example  a double  ampersand  is  used  to 
represent  a single  literal  ampersand  for  output.  Because  of 
the  use  of  the  ampersand  as  a special  character  in  assembler 
language  the  rule  for  two  ampersands  must  be  observed  when 
using  this  character  in  a self-defining  literal. 

3.4  Specifications  for  Punched  Output 
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Although  the  specifications  for  punched  output  are 
siiilar  to  printed  output,  a nuaber  of  differences  are 
indicated  in  the  following  paragraphs. 

3.4.1  Specification  of  Format  (FORMAT) 

The  specifications  for  punched  output  are  given 
separately  froa  other  formats  and  are  preceded  by  a FORMAT 
card. 

FORMAT  PUNCH  SIZE  80 

The  size  specification  (keyword  SIZE)  can  normally  be 
omitted  and  will  be  assumed  to  be  80  columns.  Other  sizes 
can  be  specified  if  desired.  The  output  program  will  check 
the  specified  output  locations  against  the  size 
specification  to  see  that  the  size  is  not  exceeded. 

3.4.2  Card  Layout  (CAP Dn) 

The  specif ications  for  card  layout  containing  data 
fields,  literal,  etc.,  are  given  on  input  cards  with  CARO  as 
the  card  type. 

CARD1  47  STATE 

The  contents  of  these  specifications  are  the  same  as 
mentioned  in  the  discussion  of  line  specifications  under 
printed  output. 

card  level  conditional  statement 
47  data  field 

CARDn  65  literal 

78  'ACTUAL  LABEL* 
action  statement 

Hhen  using  the  CARO  format,  numerically  defined  fields 
are  not  automatically  edited.  They  should  therefore  be 
edited  by  the  user  with  an  all  blank  edit  mask.  This  will 
insure  the  proper  punching  of  these  fields. 
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Areas,  i.e.  literals,  referenced  in  the  preceding 
foraats  can  be  referenced  also  in  punched  formats  provided 
the  areas  are  not  cleared  before  they  are  referenced  in  the 
succeeding  foraat.  Thus,  the  results  of  totals,  counts,  and 
calculations,  as  specified  previously,  can  be  used  only 
once. 

3.4.3  Title  and  Final  Cards  (TITLECARD,  PINALCAPD) 

Title  cards  can  be  specified  with  the  use  of  the 
TITLECARD  specification.  The  same  criteria  nust  be  followed 
for  these  cards  as  with  TITLELINE  specifications. 
Siailarly,  final  cards  can  be  specified  with  FINALCARD 
specifications. 

The  discussion  relative  to  foraat  control  is  not 
applicable  to  punched  output. 

3.4.4  Exaaple 

The  following  exaaple  of  two-position  alpha  seguencing 
on  card  output  is  shown  for  its  direct  application,  as  well 
as  for  variations  that  nay  have  other  applications. 

DEFINE  PER  CNTR1  • fUf 

CAR  Dl  ADD  91  to  CNTR1 

CARD1  80  CNTR1  SUBRT  TABlS 

Here  the  counter  (CNTR1)  will  store  the  count  as  a 
nuaeric  field  which  can  then  be  converted  to  another  fora 
using  the  subroutine  TABlS. 

3.5  Specifications  for  Tape  Output 

The  foraat  specif ications  for  aagnetic  tape  reports  also 
follow  the  sane  rules  as  for  printed  reports. 
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3.5.1  Poriat  Control  (FORMAT) 


The  basic  FORMAT  control  criteria  are  specified  on  the 
FORMAT  card  with  keywords  in  the  following  general  foraat. 

FORMAT  TAPE  NAME  SAMPLOUT  RECORD  80  BLOCK  848 


£SJLK2£d 


Function 


NAME  Bight-character  naae  to  be  used  as  the  data 

set  naae  for  the  created  data  set. 

RECORD  Record  size  (up  to  three  digits) . The  Output 

Processor  produces  variable  length  blocked 
records;  thus  the  record  size  indicated  here 
could  not  be  used  to  specify  the  actual  record 
length.  It  is  used  to  specify  a aaxiaua  record 
length  allowable.  The  4-character  record 
count  is  not  included.  If  nothing  is  specified, 
the  aaxiaua  size  will  be  200  characters. 


BLOCK  Block  size  (up  to  1004).  If  not  specified, 

the  block  size  will  be  set  to  996.  Since  the 
record  size  given  does  not  include  the  record 
character  count  (four  bytes) , each  variable  length 
record  will  actually  be  four  bytes  longer  than  the 
record  specified.  To  figure  a ainiaua  block  size, 
take  the  longest  record  length,  add  four  for  the 
record  character  count  and  add  four  for  the  block 
count.  If  all  records  are  the  saae  size  (for 
exaaple  80) , the  block  size  for  a blocking  factor 
of  10  would  be: 

[ (80  + 4)  * 10]  + 4 * 844  ♦ 4 « 848 

Note:  The  record  size  of  any  one  record  (REC0RD14  for 

exaaple)  is  the  highest  record  position  referenced.  For 

exaaple  BEC0RD14  402-FLDJC  would  generate  a 402-byte  record 
preceded  by  a record  character  count  (four  bytes)  containing 
a count  of  406.  The  aaxiaua  record  size  is  999. 
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3.5.2  Record  Card  (FECORCn) 

The  specifications  for  each  record  are  given  on  record 
input  cards  and  follow  the  saie  rules  stated  in  the 
discussion  of  printed  reports. 

record  level  conditional  stateaent 

47  data 

RECORD  n 65  liberal 

78  'ACTUAL  LABEL' 
action  stateaent 


Uhen  using  the  RECORD  foraat,  numerically  defined  fields 
are  not  autoaatically  edited.  They  should  therefore  be 
edited  by  the  user  with  an  all  blank  edit  aask.  This  will 
insure  the  proper  recording  of  these  nuaeric  fields. 

The  size  of  each  output  record  is  deterained  by  the 
largest  output  position  specified  for  that  record  plus  the 
four  positions  used  to  specify  the  record  character  count. 

In  addition,  TITLERECORDS  and  FINALRSCORDS  nay  also  be 
specified. 


. 
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Section  4 


FEPOPT  S PE Cl PTC AT TONS  SUNN  APT 


This  section  contains  a summary  of  the  specifications 
used  in  preparing  a Report  Instruction  Table  (RIT) . The 
summary  presents  in  a consolidated  manner  all  of  the 
specifications  which  are  valid  at  each  level  of  a RIT 
statement;  it  will  be  useful  as  a quick  reference  for  RIT 
preparation  and  will  facilitate  the  use  of  error 
diagnostics. 

A RIT  may  contain  up  to  five  levels  of  specifications. 
The  first  level  is  always  the  statement  type.  The  following 
example  illustrates  a 5-level  specification. 

LINE1  2<T  FLDX  SUBPT  CONVRT  IF  PLDX  GT  100 

where:  LINE1  is  a level  1 expression 

29  is  a level  2 expression 
FLDX  is  a level  3 expression 
SUBRT  CONVRT  is  a level  4 expression 
IP  FLDX  GT  100  is  a level  5 expression 

The  following  pages  contain  two  tables  which  summarize 
report  specifications.  Table  1 lists  the  valid  expressions 
at  each  of  the  five  levels.  Table  2 further  refines  these 
valid  expressions  by  presenting  those  expressions  valid  at 
each  level  by  statement  type. 

4.1  Valid  Expressions  by  Level 

The  following  table  lists  the  expressions  which  are 
considered  valid  at  each  level  by  the  OP  edit  programs. 
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Table  1 

REPORT  SPECIFICATION  SUMMART 
(Valid  Expression  by  Level) 
(Page  1 of  6) 


Level  1 Expressions  ! 

Control,  Definition,  Action  Statements 

FILE  Precedes  FORMAT  for  single  file  ^ 

FORMAT  Precedes  FILE  for  eerge  file 

DEFINE  May  appear  anywhere  before  being  used 

OMIT  After  FILE  (Note)  , 

STOP  After  FILE  (Note)  i 

MOVE  Anywhere  in  RIT  specification  \ 

COMPUTE  Anywhere  in  RIT  specification 

ADD  Anywhere  in  RIT  specification 

SUB  Anywhere  in  RIT  specification  ' 

EXTRACT  In  primary  file  of  multifile  run  * , 

GOTO  Anywhere  in  FIT  specification 

TAGn  Anywhere  in  FIT  specification 

PERFORM  Anywhere  in  RIT  specification 

RESET  Anywhere  except  within  LABEL-LINE  block 

END  Last  card  in  RIT  specification  > 

Note:  IF  OMIT  and/or  STOP  appears  before  FORMAT,  they  affect  all 

FORMATS  in  the  RIT  specifications;  if  after  FORMAT,  only 
this  format  is  conditioned. 
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Table  1 

REPORT  SPECIFICATION  SUMMARY 
(Valid  Expression  by  Level) 
(Page  2 of  6) 


Level  1 Expressions  (continued) 

Print  Statements  (Print  statements  should  appear  in  this 

sequence  when  used  in  the  FIT  specifica- 
tion. ) 

HEADER 

TITLELINE 

OVERPLOW 

LABEL 

LINE 

LINE  (IF  COMPLETE) 

FINALLINE 

TRAILER 

SPACE  Adjacent  to  associated  print  line 

SKIP  TO  Adjacent  to  associated  print  line 

EJECT  Adjacent  to  associated  print  line 

Card  Statements  (Card  statements  should  be  in  this  sequence 
when  used  in  the  punch  specification.) 

TITLECARD 

CARD 

CARD  (IF  COMPLETE) 

FINALCARD 

Record  Statements  (Record  statements  should  be  in  this  sequenc 

when  used  in  the  record  specification.) 

TITLERECORD 

RECORD 

RECORD  (IF  COMPLETE) 

FINALRECORD 
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Table  1 I 

REPORT  SPECIFICATION  SUMMARY 
(Valid  Expression  by  Level) 

(Page  1 of  6) 

I 


Level  2 Expressions 

IF  (Conditional) 

XXX 

XXX  XXX  XXX 

xxx-xxx 

TOTAL  OF  IN  1 
COUNT  OF  I IN  ” 
COMPUTE  EQ 
COMPUTE  EQ  TOTAL  OF 
COMPUTE  “ EQ  COUNT  OF 
ADD  TO~ 

SUB  “ FROM 
move”  TO 
reset” 

RESET  TO 

ALL 

SCAN 

FIRST 

LAST 

FIELDNAME 

FIELDNAME  (Partial) 
SORTKEY 

SORTKEY  (Partial) 
LITERAL  NAME 
LITERAL  NAME  (Partial) 


Line  level  condition 
Print,  card  or  record  position 
Hultiple  print  positions 
Variable  Field/Set  print 
positions 


Mode  specification  for  Set  Field 

Mode  specification  for  Set  Field 

Mode  specification  for  Set  Field 

Mode  specification  for  Set  Field 

EXTRACT  only 

EXTRACT  only 

EXTRACT  only 

EXTRACT  only 

EXTRACT  only 

EXTRACT  only 
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Table  1 

REPORT  SPECIFICATION  SUMMARY 
(Valid  Expression  by  Level) 
(Page  4 of  6) 


Level 

2 Expressions  (continued) 

IPOGRPn 

EXTRACT  only 

TAGn 

GOTO  only 

NEXT  RECORD 

GOTO  only 

LINEn 

PERPORH  only 

RECORDn 

PERPORH  only 

CAR  Cn 

PERPORH  only 

Level 

3 Expressions 

Pieldnase 

Pieldnaae  (partial) 
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Table  1 


REPORT  SPECIFICATION  SUMMARY 
(Valid  Expression  by  Level) 
(Page  5 of  6) 


Level  3 Expressions  (Continued) 

Self-defining  Literal 

Literal  Naae 

Literal  Name  (partial) 

System  Label 

TOTAL  OF 

COUNT  OF 

TOTAL  OF  ” IN 

COUNT  OF  ~ IN  I 

Arithmetic  expression 

IF  (Conditional) 

SUBRT  X 
TABLE  X 
4SUBNAME# 

• • 

FILENAME 

Level  4 Expressions 

TABLE 

SUBRT 

•Subnaae* 

EDIT 

EDIT  • • 

Edit  Hord  Naae 

«» 

• • 

#•  • • 

SUBRT  EDIT  • ' 

SUBRT  X 
SUBRT  X EDIT 
TABLE  EDIT  • • 

TABLE  X 
TABLE  X EDIT 


Use  SUBRT  X (EXTRACT  only) 
Use  TABLE  X (EXTRACT  only) 
Use  subroutine  named 
•SUBNAME'  (EXTP ACT  only) 
Override  subroutine 
(EXTRACT  only) 

(EXTRACT  only) 


May  be  automatic  (Note) 

Hay  be  automatic  (Note) 

Use  subroutine  naaed  'Subnaae' 
Use  "FT  Edit 
Use  Edit 

User-defined  edit  word 
Override  Subroutine 
Override  Edi* 

Override  Both 

Use  FFT  Subroutine  and  Edit 
Use  Subroutine  X 
Use  Subroutine  X and  FFT  Edit 
Use  FFT  Table  and  Edit 
Use  Table  X 

Use  Table  X and  PFT  Edit 
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Note: 

Level 
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Table  1 

REPORT  SPECIFICATION  SUMMARY 
(Valid  Expression  by  Level) 
(Page  6 of  6) 


IF  (Conditional) 
FILENAME  (EXTRACT  only) 


Subroutines,  Tables  and  Edits  are  not  automatic  on 
Card  and  Record  specifications. 

Expressions 

IF  (Conditional) 
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4.2  Valid  Expressions  at  Each  Level  by  Statement  Type 

The  following  table  is  a summary  of  valid  expressions, 
organized  by  stateaent  type. 
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(Conditional)  Should  immediately  follow  FILE  card  for  the  file  it 

pertains  to. 
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Table  2 

REPORT  SPECIFICATION  SUMMARY 
(Valid  Expression  by  Level  - DSPINE) 
(Page  2 of  21) 


LEVEL  1 POSSIBLE  ENTRIES 


FIELD  TYPE 


DEFINE  NAME  • • 

NANE  LLL 
NAME  B LLL 

PER  NAME  ' • 

PERIODIC  NAME  • • 

PER  NANE  LLL 
PERIODIC  NAME  LLL 

SET  (b)  NAME  • • 

SET  (b)  NAME  LLL 
PER  NAME  B LLL 
PERIODIC  NAME  B LLL 
SET  (b)  NAME  B LLL 
SET  (b)  NAME  NO RK  (N)  LLL 


SET  (b)  NAME  WORK  (N)  LLL  A 
SET  (b)  NAME  HO  RK  (N)  LLL  B 
SET  (b)  NAME  WORK  (N)  LLL  C 
SET  (b)  NANE  WORK  (N)  LLL  D 


Alphabetic,  1 to  52  chars. 

Deciaal,  1 to  999  digits 

Binary,  1 to  10  digits 

Alphabetic 

Alphabetic 

Deciaal 

Deciaal 

Alphabetic 

Deciaal 

Binary 

Binary 

Binary 

Binary  (default  aode)  , 

1 to  10  digits 

Alphabetic,  1 to  4 chars. 

Binary,  1 to  10  digits 

Coordinate,  5 to  8 digits 

Deciaal,  1 to  4 digits 
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Table  2 

REPORT  SPECIFICATION  SUNN  ARY 
(Valid  Expression  by  Level  - DEFINE) 
(Page  3 of  21) 


LEVEL  1 


POSSIBLE  ENTRIES 


FIELD  TYPE 


NAME 

i • 

Alphabetic  1 to  26 
characters 

(X) 

LLL 

Decinal 

it) 

B LLL 

Binary 

(X  , Y) 

LLL 

Decinal 

(X,  Y) 

B LLL 

Binary 

CfiflilSm 

NA  HE 


(H) 

it) 

<X,Y) 


1-7  character  literal  naae.  (lust  begin  with  an 
alphabetic  character. 

The  1-3  digit  literal  length. 

1-3  digit  set  nunber,  range  1 - 255. 

4-byte  fullword  work  areas  generated  in  the  retriever  and 
passed  to  OP  by  set  nunber.  They  nay  be  defined  as  binary 
fullwords,  internal  fora  coordinate,  1-4  byte 
alphabetic  or  decinal  fields. 

1-digit  work  area  nunber,  range  1-5. 

The  1-3  digit  occurrence  nunber. 

The  1-3  digit  row  and  colnan  nunbers. 
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Table  2 

REPORT  SPECIFICATION  SUMMARY 


(Valid  Expressions  by  Level 

(Page  h 


tevsl_l 

ADD 

TO 

SUB FROM 

BOVE 

TO 

MOVE 

SUBRT 

X TO 

BOVE 

TABLE 

X TO 

COMPUTE 

EQ 

COUNT 

OF 

COMPUTE, 

EQ  SUM  OF 

COMPUTE 

EQ 

TOTAL 

OF 

COMPUTE 

EQ 

HUL DTV 

COMPUTE 

S 

* 

. / _ 

- ADD,  SUB,  BOVE,  COBPUTE) 
of  21) 

IF  (Conditional) 


ADD  SUB 


Note:  The  above  action  statements  can  also  appear  at  levels 

2 and  3 of  other  statenents.  The  exception  is  when  a 
■atrix  is  being  generated  Making  use  of  SUB  OF  or 
COUNT  OF.  Batrix  generation  statenents  are  only  valid  at 
level  1. 
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Table  2 

REPORT  SPECIFICATION  SUNK  ARY 
(Valid  Expressions  by  Level  - RESET,  SPACE,  SKIP,  EJECT) 

(Page  5 of  21) 


POSSIBLE  ENTRIES 

tillin  XiiiO 

RESET  Literal  Name  IF  (Conditional) 

System  Label 

Literal  Name  TO  

System  Label  TO  

Note:  Areas  are  either  reset  to  zeros  or  to  the  literal 

specified  with  a true  sign. 


SPACE  n IF  (Conditional) 

n BEFORE  (card  type) 
n B ETWEEN  RECORDS 
n = Number  of  spaces  required 


EJECT  BEFORE  (card  type)  IF  (Conditional) 

BETWEEN  RECORDS 


SKIP  TO  n IF  (Conditional) 

n BEFORE  (card  type) 
n BETWEEN  RECORDS 
n * Carriage  channel  to 
SKIP  TO 


Note:  If  a format  statement  and  a conditional  statement  appear 
on  the  sane  line  for  SPACE,  SKIP  TO,  or  EJECT,  then  the 
conditional  statement  must  be  last. 


106 


- 


r 


I 


OUTPUT  PROCESSOR  (OP) 


Table  2 

REPORT  SPECIFICATION  SUMMARY 

(Valid  Expressions  by  Level  - HEADER,  TRAILER,  TITLELINE, 
TITLECARD,  TITLERECORD) 

(Page  6 of  21) 


POSSIBLE  ENTRIES 


ieSISl-l. 

HEADER  (nnn)  IF  (Conditional) 

TRAILER (nnn)  XXX 

TITLELINE (nnn) 

TITLECARD (nnn) 

TITLERECORD  (nnn) 

Lei§l_ I i§vel_4 

XXX  • • IF  (Conditional)  ^ 

Systen  Label 
Literal 

SORTKEY  X/Y  (Note) 

SORT  X/Y  (Note) 


SSfiflEJlIS 

nnn  3 1-3  digit  line  level  (Alpha  levels  say  be  used  but 
should  not  be  nixed  with  nonalpha  levels) 

XXX  * 1-3  digit  print  position  (This  position  is  the  low- 
order  (rightnost)  position.) 

X/Y  = partial  field  notation 

Note:  The  partial  field  notation  for  the  sort  key  nust  not 
include  positions  1-3  of  the  sort  key. 


I 

I 
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Table  2 

REPORT  SPECIFICATION  SUMMARY 
(Valid  Expressions  by  Level  - LABEL) 
(Page  7 of  21) 


POSSIBLE  ENTRIES 

iave±_i 

Ievel_2 

LABELnnn 

IF  (Conditional) 

LABEinnna 

XXX 

PERIODIC 

PER 

SET (b) 

i&zll.i  iiilLi* 

XXX  • ' IF  (Conditional) 


Systea  Label 
Literal 

SORTKEY  X/Y  (Note) 
SORT  X/Y  (Note) 


Note 


The  partial  field  notation  for  the  sort  hey  aust  not 
include  positions  1-3  of  the  sort  hey. 
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Table  2 

REPORT  SPECIFICATION  SUNN  ARY 
(Valid  Expressions  by  Level  - LABEL) 
(Page  8 of  21) 


POSSIBLE  ENTRIES 


ca  mm 

nan  =1-3  digit  line  level 

nnna  = Alpha  line  level  which  is  a 1 - 1 digit  nuaber  followed 

by  one  alphabetic  character  1 

XXX  =1-3  digit  print  position  (This  is  the  low-order  (right-  j 

■ost)  position.)  i 

(b)  =1-3  digit  set  nuaber 

X/Y  = partial  field  notation  j 

J 

Notes:  Label  lines  with  alphabetic  level  designation  should  have  ' > 

only  one  alpha  level  conditional  expression  per  group  of  |( 

labels.  The  conditional  should  precede  the  group, 
and  should  contain  the  alpha  character  which  starts 
the  group. 

* 

The  partial  field  notation  for  the  sort  hey  aust  not 
include  positions  1-3  of  the  sort  key. 
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Table  2 

REPORT  SPECIFICATION  SUMMARY 

(Valid  Expressions  by  Level  - LINE,  CARD,  RECORD,  OVERPLOB) 

(Page  9 of  21) 


POSSIBLE  ENTRIES 


L§vei_2 

LINEnnn 

IF  (Conditional) 

LINEnnna 

XXX  XXX  XXX 

CARDnnn 

XXX 

CARDnnna 

RECORDnnn 

Action  Expression 

(Croup  1) 

SECORDnnna 

OVERFLOBnnn 

XXX/XXX  Variable 

Field 

OVERFLOBnnna 

ALL 

ALL  SET  ( b) 

SCAN 

SCAN  SET  (b) 

FIRST  ■ 

FIRST  ■ SET (b) 

LAST  ■ 

LAST  ■ SET(b) 

■ is  the  count  for  FIRST 
and  LAST.  Range  is  1 - 
255. 
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Table  2 

REPORT  SPECIFICATION  SUMMARY 

(Valid  Expressions  by  Level  - LINE,  CARD,  RECORD,  OVERFLOW) 

(Page  10  of  21) 


POSSIBLE  ENTRIES 


LSISl.l 


ievel_2  Lev£l_3 

XXX  Field  Nane 

XXX  Literal 

XXX  Systea  Label 


XXX 

1 1 

LSI  SlJ* 

PERIODIC 

PER 

SET (b) 

XXX 

Field  Naee 

EDIT 

Action  Expression 

TABLE  use  FFT 

(Group  2) 

entry 

Literal 

SUBRT  use  FFT  entry 

EDIT  'edit  word* 

SUBRT  NAME 

TABLE  NAME 

•SUB/TAB* 

#•  (override  FPT 
Subrt) 
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Table  2 

REPORT  SPECIFICATION  SUNMAPY 

(Valid  Expressions  by  Level  - LINE,  CAP D,  RECORD,  OVERFLOW) 

(Page  11  of  21) 


POSSIBLE  ENTRIES 


Ley§i_4  (Cont'd) 

••  (override  FFT 
Edit) 

IF  (Conditional) 


IF  (Conditional)  (Applies  when  a TABLE/SUBPT/EDIT  expression  is 

at  level  4) 


SQAOfm 

nnn  * 1 - 3 digit  line  level 

nnna  = Alpha  line  level  which  is  a 1 - 3 digit  nuaber 
followed  by  one  alphabetic  character. 

XXX  =1-3  digit  print  position 

(b)  =1-3  digit  set  nuaber 

a =1-3  digit  count  for  FIRST  or  LAST 

Note:  OVERFLOW  is  like  FINALLINE  if  the  RIT  is  a serge  file 

BIT.  No  file  fields  are  allowed. 
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Table  2 

REPORT  SPECIFICATION  SUMMARY 

(Valid  Expressions  by  Level  - FINALLINE,  FINALCARD,  FINALRECORD) 

(Page  12  of  21) 


POSSIBLE  ENTRIES 


tSISl-l  Level_2  Level_3  L£l£l_4 

FINALLINEnnn  IF  (Conditional) 


FINN AL LIN Ennna  XXX 

XXX  XXX  ... 

FINALCAROnnn 

FINALCARDnnna 

FINALRECOROnnn 

FINALRECORDnnna 


Action 
Expression 
(Group  3) 


• • IF  (Condi- 

tional) 

Array  or  Matrix 
Systee  Label 
Literal 

SORTKEY  X/Y  (Note) 

SORT  X/Y  (Note) 

Action  Expression  (Group  2) 
only  difference  between 
HEADERS,  TRAILERS, TITLELINES 
TIT  LECAPDS 

IF  (Conditional) 


Note:  The  partial  field  notation  for  the  sort  key  a ust  not 
include  positions  1-3  of  the  sort  key. 
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Table  2 

REPORT  SPECIFICATION  SUNN  ART 

(Valid  Expressions  by  Level  - FINALLINE,  FINALCARD,  FINALRECORD) 

(Page  13  of  21) 


POSSIBLE  ENTRIES 


S2MMIS 

nnn  =1-3  digit  line  level 

nnna  = Alpha  line  level  which  is  a 1 - 3 digit  number  followed 
by  one  alphabetic  character 
XXX  =1-3  digit  print  position 
X/Y  = partial  field  notation 

Notes:  No  file  fields  are  allowed  except  in  certain  action  expres- 
sions, namely  COUNT  OF , TOTAL  OF , TOTAL  OF IN , 

COUNT  OF IN___.  In  merge  file  reports,  file  fields  are 

not  allowed  in  FINALLINES,  FINALCARDS,  or  FINALPECORDS. 

The  partial  field  notation  for  the  sort  key  must  not 
include  positions  1-3  of  the  sort  key. 
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REPOST  SPECIFICATION  SUMMARY 
(Valid  Expressions  by  Level  - IF  (Conditional)) 
(Page  15  of  21) 


POSSIBLE  CONDITIONAL  EXPRESSIONS 


OPERATOR 

PAS*aiTI£_ 

M 

LTE 

LESS  THAN  OF 

EQUAL 

M 

LE 

LESS  THAN  OR 

EQUAL 

If 

NGTE 

NOT  GREATER  ' 

THAN  OR 

EQUAL 

N 

GTE 

GREATER  THAN 

OR  EQUAL 

N 

GE 

GREATER  THAN 

OR  EQUAL 

ff 

CO NTAINS 

ft 

ABSENT 

Note:  'NOT'  eay  be  placed  in  front  of  any  operator. 


Parameters  eay  be  data  fields,  literals,  system  labels,  and 
defined  literals.  Limitations  depend  on  the  literal  or 
field  name  type  and  the  statement  on  which  the  condition 
appears.  Reference  should  be  made  to  the  statement  type 
(level  1)  for  further  restrictions  on  parameters. 


AND  and  OR  nay  be  used  to  link  ‘parameter  operator  param- 
eter* strings. 

The  following  conditional  expressions  illustrate  processing  of 
condition  logic. 

NON-BOOLEAN  - Normal  mode  of  condition  code  generation  - 


Bl££eaai2fl  latfitpretatioE. 

IF  A AND  B Both  A and  B must  be  true  for  the  condition 

to  be  net. 


IF  A OR  B 


Either  A or  B must  be  true  for  the  condition 
to  be  met. 


I 
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Table  2 

REPORT  SPECIFICATION  SIH1NARY 
(Valid  Expressions  by  Level  - IF  (Conditional) 
(Page  16  of  21) 


POSSIBLE  CONDITIONAL  EXPRESSIONS 


IHt£r££2tltiOQ 

C Bust  be  true  and  either  A or  B aust  also  be 
true  for  the  condition  to  be  net. 

• punched  as  ♦he  last  parameter  on  the 
CREATE  card. 


Iai£L££2taU2L 

Both  A and  B aust  be  true  for  the  condition 
to  be  net. 

Either  A or  B aust  be  true  for  the  condition 
to  be  net. 

Both  A and  B must  be  true,  or  C must  be  true 
for  the  condition  to  be  aet. . 


k 


El£I£s§ion 
IF  A OR  B AND  C 

BOOLEAN  LOGIC  • BCOL 

£££££35120 
IF  A AND  B 

IF  A OR  B 

IF  A AND  B OR  C 


- 
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Table  2 

REPORT  SPECIFICATION  SUMMARY 
(Valid  Expressions  by  Level  - Action  Statement) 
(Page  17  of  21) 


POSSIBLE  ACTION  STATEMENTS  BY  GROUP 


Group  1 Action  Expressions 

1.  TOTAL  OF IN 

2.  COUNT  OF IN 

3.  COMPUTE EQ I 

4.  COMPUTE EQ  TOTAL  OF 

5.  COMPUTE ~EQ  COUNT  OF 


6. 

ADD,,  , 

TO 

7. 

SUB 

FROM 

8. 

BESET 

9. 

RESET. 

TO 

10. 

HOVE__ 

TO 

11. 

MOVE 

SUBRT  NAME 

TO 

12. 

HOVE 

TABLE  NAME 

TO 

13. 

COMPUTE EQ  SUM 

OF 

Group  2 Action  Expressions 


1.  TOTAL  OF 

2.  COUNT  OF 

3.  Arithmetic  Expression  (X  DIV  Y,  X NUL  Y,  etc.) 

4.  TOTAL  OF  IN  

5.  COUNT  OF IN 

Note;  Group  2 action  expressions  say  be  followed  by  SUBHT,  TABLE  or 
EDIT  if  at  level  3. 
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Table  2 

FEPOPT  SPECIFICATION  SUMMARY 
(Valid  Expressions  by  Level  - Action  Statement) 
(Page  18  of  21) 


POSSIBLE  ACTION  STATEMENTS  BY  GROUP 


Group  1 Action  Expressions 

TOTAL  OF IN 

COUNT  OF “IN 

COMPUTE EQ 

ADD TO 

SUB  FROHl 

MOVE TO_3_ 

RESET 

RESET  TO 


I 


I 
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Table  2 

REPORT  SPECIFICATION  SUMMARY 
(Valid  Expressions  by  Level  - EXTRACT) 
(Page  19  of  21) 


POSSIELE  ENTRIES 


EXTRACT 


Level-2 

FIELDNAME 
LITERAL 
SORTKEY 
IFOGRPn  (Note) 


ltSlSl.3 

SUBRT  NAME 
TABLE  NAME 
#S  UBM  AM  Ei 

• • 

FIELDNAME 
IF (conditional) 


iavel_4 

FILENAME 
IF (conditional) 


L2I£l_5 

IF (conditional) 


Note:  n is  any  alphanumeric  character 
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i§iel_1 

PERFORM 


Tabl«i  2 

REPOPT  SPECI FICATION  SUMHART 
(Valid  Expressions  by  Level -PERFORM) 
(Page  21  or  21) 


POSSIBLE  EHTRIES 


Level_2 

LINEnnn  (NOTE) 
CARDnnn  (NOTE) 
RECORDnnn  (Note) 


Ley.£l_3 

IF  (Conditional) 


Note:  nnn  is  the  1-3  digit  line  level 
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4.3  BIT  Code  Generation  Organization 

Publishing  a RIT  involves  execution  of  the  code  which  is 
generated  by  OP  from  the  report  specification  cards.  The 
sequence  of  RIT  output  is  determined  by  the  generation  and 
execution  of  this  code  in  "sections,"  and  within  sections  by 
"blocks."  Following  is  a discussion  of  sections  and  blocks 
of  code. 


4.3.1  RIZ  Sections  of  Code 

For  each  data  record  (or  sort  key)  which  is  sequentially 
accessed  by  OP,  the  first  section  of  code  to  be  executed  is 
one  which  handles  processing  of  HEADERS,  TRAILERS, 
OVERFLOWS,  TITLELINES,  TITLFCAP DS , TITLEPECORDS , FINALLINES, 
FINALCARDS,  and  FINALRECORDS.  These  specification  cards  do 
not  appear  together  in  a RIT  structure  deck,  but  are 
processed  together  for  execution. 

The  second  section  of  code,  the  File  Control  section,  is 
aade  up  of  different  types  of  RIT  specifications,  depending 
on  where  the  user  has  placed  the  card  in  his  RIT  structure 
deck.  For  exaeple,  in  a single  file  RIT,  OMIT,  STOP, 
COMPUTE,  RESET,  ADD,  SUB,  and  MOVE  statements  are  processed 
in  this  section  if  they  appear  before  the  first  FORMAT  card. 
If  these  statements  appear  after  a FORMAT  card  they  are 
processed  within  the  data  section  for  that  FORMAT  and  would 
not  be  executed  within  the  File  Control  section.  In  a merge 
file  RIT,  the  File  Control  section  contains  those  statements 
(OMIT,  STOP,  COMPUTE,  RESET,  ADD,  SUB,  and  MOVE)  which  occur 
after  a FILE  card  and  prior  to  the  first  LINE  statement  for 
the  particular  file.  Examples  are  shown  in  section  5,  "Run 
Deck  Formats,"  concerning  inclusion  of  RIT  specifications 
within  the  File  Control  section. 

The  Breaklines  section  of  code  is  executed  next  and 
contains  the  IF  COMPLETE  line  specifications.  This  section 
uses  values  saved  from  the  previous  record  and  is  therefore 
not  executed  on  the  first  record. 

Following  Breaklines,  the  SAVE  section  moves  values  to 
save  literals  for  LINES,  CARDS,  and  RECORDS.  This  section 
also  maintains  TOTAL  OF  and  COUNT  OF  work  areas. 
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The  PRINT  section  is  then  executed.  It  processes  OMITS 
and  STOPS  (appearing  after  FCRMA?  PPINT  card) , and  LABEL  and 
LINE  specifications.  At  this  point,  all  output  for  FORMAT 
PRINT  is  coaplete. 

The  next  section  is  one  to  process  IF  COMPLETE  card 
specifications,  IF  COMPLETE  record  specifications,  CARDS, 
and  RECORDS.  If  a particular  foreat  is  not  required,  the 
coding  for  that  section  will  consist,  of  a return  to  the 
calling  prograe.  Note  that  in  a nultiforaat  PIT,  the 
foraats  will  always  be  executed  in  the  above-described 
sequence,  regardless  of  the  user's  deck  sequence. 

Uhen  nore  than  one  file  is  eentioned  in  the  RIT,  there 
is  a repetition  of  these  sections  of  code  for  each 
additional  file. 


4.3.2  RIT  Blocks  of  Code 


Hithin  a section,  code  is  executed  in  "blocks."  A 
"block"  is  all  statenents  associated  with  a LINE.  For 
example  "LINE3". 


e.g.  LINE2  20  ITEM1 

SPACE  2 BEFORE  LINE3 
LINE  3 IF  ITEM 2 COMPLETE 
LINE3A  20  ITEM 3 
LINE 3B  22  ITSM4 

Block  LINE3C  30  TOTAL  OF  ITEM5 

LINE3C  COMPUTE  AA  EQ  BB  t CC 
SPACE  2 

EJECT  IF  BODYLINES  LT  10 
LINE4  30  ITEM6 
LINE5  40  AA 


Action  statenents,  (including  ADD,  SUB,  HOVE,  etc.) 
which  are  not  specified  on  a line,  are  also  executed  in 
blocks.  Blocks  are  formed  from  contiguous  action  statements 
making  reference  to  the  sane  set. 


e.  g. 

ADD 

ADD 

FLDXA 

FLD1A 

TO 

TO 

BUCKET 

BUCKET 

(fixed  set) 

BLOCK 

SUB 

HOVE 

FLD1B 

FLD1C 

FROM 

TO 

BUCKET 

HOLD1 

(Periodic  Set 

1) 

MOVE 

FLD2A 

TO 

HOLD  2 

(Periodic  Set 

2) 
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l< 
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A block  is  cycled  through  until  the  referenced  set  or 
sets  are  exhausted.  Control  is  then  passed  to  the  next 
block. 

The  aeount  of  code  generated  for  a block  eay  not  exceed 
8,000  bytes.  All  user-defined  and  OP-generated  literals  are 
also  grouped  into  a data  block  which  is  liaited  to  8,000 
bytes. 


A i 
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Section  5 

RUN  DECK  PORHATS 


The  Material  in  this  section  illustrates  a typical 
sequence  of  specification  cards  which  could  appear  within  an 
OP  run  deck.  Examples,  with  commentary,  are  first  given  for 
structuring  RITs  with  all  combinations  of  files  and  formats. 
The  deck  sequence  is  then  illustrated  for  runs  in  which  RITs 
are  executed  but  not  structured.  A third  section  shows  the 
sequence  for  jobs  in  which  both  structuring  and  execution  of 
the  RITs  are  accomplished. 

5.1  OP  RIT  Structure 

At  the  end  of  an  RIT  structure  run,  a load  nodule  RIT 
(ready  for  execution)  has  been  placed  on  a library 
(temporary  or  permanent)  for  each  set  of  RIT  specifications 
(CREATE  through  END  cards).  No  RITs  are  executed  and  no 
reports  are  produced  in  a structure  job. 

5.1.1  Single  Pile  Print  format 

in  a single-file  RIT,  data  records  are  processed 
sequentially  from  the  file  if  the  RIT  is  executed  SOURCE 
DIRECT.  If  the  RIT  is  executed  SOURCE  RETRIEVAL,  there  is 
a sequential  pass  of  the  QRT  with  access  to  each  associated 
data  record  on  the  Qualifying  Data  Pile  (QDF) . A single  RIT 
may  be  structured  for  both  SOURCE  DIRECT  and  SOURCE 
RETRIEVAL  executions  (in  separate  jobs)  assuming  RIT 
specifications  are  the  sane. 
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2j.Aal£-Eilfi_P£iii£_£2£iat  Stmia 


CREATE  RITID  = Rit.  naae  STORE* PERH-N BW 
FILE 

OMIT,  STOP,  COMPOTE,  RESET, 

ADO,  SUB,  HOVE 

FORMAT  PRINT 

OMITS,  STOPS 

HEADERS 

TITL ELINES 

OVERFLOWS 

LABELS 

LINES 

LINES  IF COMPLETE 

EJECT  BETWEEN  RECORDS  IF  COMPLETE 


Pile  Control  section 


Top  of  each  page 
Once  at  beginning 
Top  of  page  if  not  line 
Print  section 

Breaklines  section 


•1 


Note:  Breaklines  are  grouped  after  all  other  lines 
FINALLINES  End  of  report 

TRAILERS  End  of  page 

END 


SPACE,  SKIP  and  EJECT  adjacent  to  any  printed  line. 

COMPUTE,  ADD,  SUB,  MOVE,  RESET  and  DEFINE  eay  be  anywhere. 

GOTO  and  the  associated  TAG  aay  be  placed  anywhere  in 
the  Print  and  Breakline  sections.  They  aay  not  traverse  the 
boundaries  between  these  sections.  The  saae  holds  true  for 
the  PERFORM  stateaent. 


I 

; 

i 


i 
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5.1.2  Single  Pile,  Multi  format 

Iu  a multiformat  RIT,  execution  of  the  formats  is  always 
in  the  order  of  PRINT,  PUNCH,  TAPE,  regardless  of  the  user's 
deck  sequence.  Use  of  the  OMIT  and  STOP  statements  with 
different  formats  is  discussed  in  section  3.3.7, 
"Conditional  Exclusion  of  Data  Records,"  section  3.3.7, 
"Stopping  the  Report  Conditionally,"  and  section  3.3.17, 
"Expanded  Arithmetic  Operations  (TOTAL,  STOP,  OMIT,  COUNT, 
COMPUTE)  ." 


CREATE  RITID=Ritname  STOFE=P»RM-NEH 
PILE 

OMITS,  STOPS  Pile  Control  section 

Entire  report 

FORMAT  PRINT 

(See  Single  Pile  Print  Pormat) 

£2MAI_EMCH 

OMITS  This  format  only 

STOPS  For  remainder  of  PIT 

TITLECARDS 


J 


CARDS 


Card  section 


CARDS  (IP  COMPLETE) 
FINALCARDS 


Break  Cards  section 
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l 

I 

I 

I 


. 


I 

1 


i 


* 


' I 


£0mi_lAPE 

OMITS 

STOPS 

TITLERECORDS 

RECORDS 

RECORDS  (IP  COMPLETE) 
PINALRECORDS 


This  format  only 
Por  remainder  of  RIT 

Record  section 
Break  Records  section 


END 


COMPUTE,  ADD,  SUB,  MOVE,  RESET,  and  DEPTNE  may  be  anywhere. 

GOTO  and  TAG  may  go  in  the  PRINT,  CARD,  and  RECORD 
sections  as  well  as  their  associated  Break  sections.  They 
may  not  traverse  the  Break  section  boundaries  or  those 
between  formats.  The  same  holds  true  with  the  PERPORM 
statement . 

5.1.3  Merge  Pile,  Single  Pormat 

A merge  file  RIT  is  executed  following  a RASP  step  and 
processes  a QDP  and  QRT.  As  each  entry  in  the  QRT  is 
accessed  sequentially,  the  associated  data  record  in  the  QDP 
is  processed  with  those  RIT  statements  for  the  specific  file 
which  contains  the  current  data  record.  Specifications  in 
the  RIT  for  different  files  automatically  generate  separate 
processing  blocks  of  code  so  that  equal  line  numbers  in 
different  file  sections  of  the  RIT  will  not  cause  data  to  be 
printed  on  the  same  physical  print  line.  work  areas  defined 
in  the  RIT  are  common  to  all  files.  Therefore,  data  from 
different  files  can  be  saved  in  work  areas  and  output  on  one 
physical  print  line. 
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flatae_Zilaj._5insil9_Z2Lsal  Estates 

CREATE  RITID=Ritnaae  STORE= PERM- NEW 

FORMAT  PRINT 

HEADERS 

TITLELINES 

OVERFLOW'S  No  file  fields 

FILE  X 

OMITS,  STOPS,  Action  Statements  This  format  only  - File 

Control  section 

LINES 

LINES  (IF  COMPLETE)  If  complete  lines  by  file 

FILE  X 

OMITS,  STOPS,  Action  Statements  File  Control,  File  I 
LINES 

LINES  (IF  COMPLETE) 

FINALLINES  File  fields  not  allowed 

TRAILERS 

END 

Note:  File  Control  includes  all  action  statements  before  the 
first  LINEnnn. 

The  EXTRACT  statement  may  only  be  specified  within  the 
specifications  for  the  first  file,  FILE  X. 
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5.1.4  Merge  Pile,  Hultiforaat 

In  a aerge  file,  aultifornat  RIT,  the  data  record 
associated  with  each  sort  key  is  processed  in  the  saie  way 
discussed  in  section  5.1.3,  "Merge  File,  Single  Poraat." 
During  processing  of  each  data  record,  the  foraats  are 
always  executed  in  the  order  of  PRINT,  PUNCH,  TAPE. 

fls£ae_Eiia*_auLtiio£sat  fieiatks 

CREATE  RITI D=Ritnaae  STORE*PERH- NEM 

HEADERS 

TITLELINES 

OVERFLONS  No  file  fields 

FILE  1 

UBELS,  LINES 

FILE  2 

LABELS,  LINES 

FINALLINES  No  file  fields 

TRAILERS  NO  file  fields 

TITLECARDS 
FILE  1 

CARDS 

FILE  2 
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CARDS 

FINALCARDS 

ISm£_IA££ 

TITLE RECORDS 

FILE  1 

RECORDS 

FILE  2 

RECORDS 

FINALRECORDS 

END 


The  EXTRACT  statement  aay  only  occur  vithin  the 

apecificationn  for  PILE1  in  the  PRINT,  CARD,  and  RECORD 
f ornate. 

5.2  OP  RIT  Execution 

In  one  OP  Execution  run,  one  RIT  will  be  executed  for 
each  PUBLISH  card.  The  execution  nay  be  SOURCE  DIRECT  or 
SOURCE  RETRIEVAL  but  not  both  in  one  execution  of  OP. 

5.2.1  SOURCE  DIRECT 

SOURCE  DIRECT 

PUBLISH  RITID-Ritnaae  BODYLINES*4(F  CLASS-UNCLASSIFIED 

5.2.2  SOURCE  RETRIEVAL 

£LbU&k_££fil_£9lEift2al_A!18«£E_S2t 

SOURCE  RETRIEVAL 

PUBLISH  RITID-Ritnane  ANSID«nn  CLASS-UNCLASSIFIED 


OUTPUT  PBOCESSOF  (OP) 


5.3  OP  RIT  Structure  and  Execution 

In  one  OP  run,  RITs  aay  be  structured  and  executed.  All 
structure  specifications  (CREATE  cards)  cone  before  the 
SOURCE  card,  and  all  execution  specifications  (PUBLISH  card) 
follow  the  SOURCE  card.  The  run  aay  be  SOURCE  DIRECT  or 
SOURCE  RETRIEVAL  but  not  both  in  one  execution  of  OP. 
Teaporary  and  pernanent  RITs  aay  be  used  in  the  sane 
execution  of  OP. 

5.3.1  Peraanent  RITs 

Si2L2_£II_£9Iia£Snill 

CREATE  RITID-Ritnane  STORE-PERH -NEW 
(RIT  STRUCTURE  CARDS) 

END 

SOURCE  DIRECT 

PUBLISH  RITID-Ritnaae  DAT E-19M AR68  CLASS-UNCLASSIFIED 

5.3.2  Teaporary  RITs 

5£flI9_aiI_l£i£2IftEil.Y 

CREATE  R ITID-Ritnaae  STORE-TEHP 

(RIT  Structure  Cards) 

END 

SOURCE  DIRECT 

PUBLISH  SPECI AL-Ritnaae  CLASS-UNCLASSIFIED 


133 


OUTPUT  PROCESSOR  (OP) 


5.3.3  Permanent  and  Teaporary  RITs  in  One  Job 

CREATE  RITID*TEMPl  STORE-TEMP 
(HIT  STRUCTURE  CARDS) 

END 

CREATE  RITID-PERH1  STORE-PERH-NEN 
(RIT  STRUCTURE  CARDS) 

END 

CREATE  R ITID=PERN  2 STORE=PERM-NEM 
(RIT  STRUCTURE  CARDS) 

END 

SOURCE  DIRECT 

PUBLISH  SPECIAL=TEf!Pl  CLASS-UNCLASSIFIED 
PUBLISH  RITID-PERHl  DATE='12  PFB  1970' 

PUBLISH  R IT ID-PERM  5 PAR AN-X YZ  C LASS-UMCLASSIFIED 

In  this  exaaple,  the  RIT  naae  TEMPI  is  structured, 
stored  on  the  Teaporary  Library,  and  executed.  The  RIT 
naaed  PERMl  is  structured,  stored  on  the  Peraanent  Library, 
and  executed.  The  RIT  naaed  PER  M2  is  structured  and  stored 
on  the  Peraanent  Library  but  not  executed  in  this  run.  The 
RIT  naaed  PERN5  is  executed  froa  the  Peraanent  Library. 

5.4  Checkpoint/Restart 

During  SAM  processing,  the  user  aay  invoke  the  OS  360 
check  point/restart  capability  to  record  tiaed  or  end-of- 
volume  checkpoints.  T f checkpoints  are  needed  during  ISAM 
processing,  only  the  tiaed  option  is  valid.  The 
checkpoint/restart  should  only  be  used  during  long-running 
jobs  using  the  execute  only  procedures.  (Note  that  the  OS 
360  step  restart  is  prograa  independent  and  is  not  the  topic 
of  this  discussion.)  A detailed  description  of  the  OS  360 
checkpoint/restart  capability  (which  is  utilized  in  NIPS)  is 
available  to  the  interested  user  in  IBM  Systeas  Reference 
Library,  Nuaber  C28-6708.  A detailed  description  on  how  to 
use  checkpoint/restart  is  included  in  voluae  VIII,  Job 
Preparation  Manual. 
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Section  6 


SUPPORTING  FEATURES 


This  section  describes  features  outside  the  OP  component 
which  support  its  operation, 

6.1  Operating  Systea/360 

The  Output  Processor  operates  within  the  S/360  Operating 
Systea.  S/360  OS  is  included  as  a supporting  itea  only  to 
■ahe  the  user  aware  that  aany  of  the  features  of  the 
operating  systea  are  used  by  NIPS  or  can  be  used  to 
suppleaent  the  capability.  Faailiarity  with  OS  will  be  aost 
useful. 

6.2  Coordinate  Conversion 

Coordinate  fields  are  carried  in  the  data  file  in  a 
special  internal  foraat  to  facilitate  various  geographic 
searches.  The  field  is  automatically  converted  to  an 
external  foraat  by  the  Output  Processor.  The  foraats  are  as 
follows: 


Output  Length 


Result 


1 ' 


DDHHN/S 

DDDHNE/N 

DDHHSSN/S 

DDDHHSSE/W 

DDHHN/SDDDHHE/W 

DDHHSSN/SDDDHHSSE/W 


OUTPUT  PROCESSOR  (OP) 


Coordinate  Position 

D = DEGREES 
N * MINUTES 
S * SECONDS 

Directional  Position 

N = NORTH 
S = SOUTH 
E = EAST 
H = WEST 

To  access  a portion  of  a coordinate  field,  such  as  in  a 
comparison  for  degrees,  the  field  eust  first  be  moved  to  a 
user-defined  work  area  using  the  system  subroutine  UTCORDO. 
Assume,  for  example,  a coordinate  field  named  LAT  (output 
length  5) : 


DEFINE  AREA  5 

HOVE  LAT  SUBRT  UTCORDO  TO  AREA 
LINEn  ....action...,  IF  AREA  1/2  GT  30 
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Section  7 


SUMMARY  OP  1410  NIPS  and  NIPS  360  FFS  CHANGES 


This  section  is  included  as  a conversion  aid  for  NIPS 

1410  FFS  users  who  wish  to  use  the  control  language  of  NIPS 

360  FFS.  There  are  no  language  changes  which  would  force 

nodif ications  to  an  existing  RIT  before  it  could  be 

structured.  However,  certain  restrictions  will  be  inposed 
on  the  user.  These  restrictions  fall  into  the  category  of 
actions  not  reconnended  or  warned  against  in  NIPS  1410  FFS, 
but  allowed.  In  NIPS  360  FFS,  they  will  not  be  allowed. 
Also,  there  are  a United  nunber  of  expansions  which  the 
user  night  desire  to  use. 

7.1  Alpha  Literals 

Alpha  literals  nay  be  enclosed  in  at  (3)  signs  or  quote 
(')  signs.  The  quote  (')  and/or  anpersand  (6)  will  be 
illegal  within  the  literal,  and  will  result  in  a non* 
structured  condition. 

Exanples: 

DEFINE  LABEL  SEX  AMPLE  ALPHA  LITERALS 
sane  as 

DEFINE  LABEL  'EXAMPLE  ALPHA  LITERAL' 

The  following  is  illegal: 

DEFINE  LABEL  'ILLEGAL  TO  USP  6 OR" 


J 


> 


l 


i 


I 
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7.2  Binary  Literals 

This  new  literal  allows  the  user  to  perform  arithmetic- 
type  operations  on  binary  fields  without  conversion. 

Example: 


DEFINE  WORK*  B nn  nn*Length  of  output 


7.3  Subroutine  Table  and  Edit  Designation 

A fieldname  (printed)  with  no  subroutine/table/edit 
designation  will  default  to  the  output  subroutine/table/edit 
functions  specified  in  the  EFT.  A fieldname  followed  by  the 
word  SO BBT,  TABLE,  or  EDIT  will  do  the  same.  The  PFT 
designation  can  be  overridden  by  the  fieldname  followed  by 
§•  (subroutine  or  table)  or  "(quote,  quote  for  edit).  The 
output  will  be  in  file  form  or  it  can  be  overridden  by 
ISUB/TAB#,  SOBRT  SUBNAHE,  TABLE  TABNAHE,  EDIT  'edit  mash', 
or  the  name  of  a defined  edit  mask  and  the  data  will  be 
processed  using  the  designated  subroutine,  table,  or  edit 
mask. 

Examples: 

LIhEl  20  SERV  ) 

) Uses  subroutine  or  edit  word 

LIhEl  20  SERV  SUBRT  ) designated  in  FFT 

LIhEl  20  SERV  ••  Output  will  be  in  file  form 

LIhEl  20  SERV  #SUB  X#  ) 

) Output  will  be  processed 

LINE1  20  SERV  SUBRT  S(IBX)  by  subroutine  SUBX 


7.4  HOVE,  ADD,  SOB  Statements 

These  new  statements  allow  the  user  to  perform  these 
actions  without  creating  dummy  (blank)  lines  and  then 
conditioning  then  out.  In  essence,  they  are  on  the  same 
level  as  the  LINE,  RECORD,  CARD,  etc. 
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Exaaples: 

HOVE  A TO  B 
ADD  A TO  B 
SUB  A FROH  B 


Level  1 Action 


HOVE  A TO  B IF  A CHANGES  Level  1 Conditional  Action 

7.5  PARAH  Systea  Label 

This  systea  label  allows  the  usee  to  introduce 
inforaation  to  the  RIT  at  execution  tine.  It  is  a 60-byte 
EBCDIC  field. 

Exanple: 

LINE  1 IF  PARAH  1-1  EQUAL  'A*  Test  the  first 

character  of  PARAH  for  A 


7.6  Partial  Field  Designation 

The  HOP  and  LOP  on  partial  field  designation  can  be 
separated  with  either  a - (dash)  or  /(slash)  . 

Exanple: 

LINE  l IP  SORT  5-6  CHANGES) 

) Partial  field  designation 
Lit'  i.  IF  SORT  5/6  CHANGES)  is  the  saae 

7.7  OP  Control  Cards 

7.7.1  Source  Off-line 

Not  valid.  Sane  results  can  be  obtained  through  S/360 
os  and  the  utility  prograns. 

7.7.2  Create 

The  CREATE  card  has  been  expanded  to  allow  the  user  soae 
control  over  the  disposition  of  the  RIT.  Note,  however, 
that  "Special"  RITs  aust  now  have  a CREATE  card. 
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Exaaples: 

a.  CREATE  RITAR 


b.  CREATE  RITID=RITNAHE 
ST ORE* PERU -OLD 


c.  CREATE  HITID=RITNAHE 
ST ORE* PERU -NEW 


d,  CREATE  RITID*RITNAHE 
STORE*TEHP 


e.  CREATE  RITID*R ITNA HE 
DEBUG 


f.  CREATE  RITID*RITNAME 
STORE* PERN -HER  BOOL 


Will  result  in  the  RIT  RITAR 
being  structured  and  stored  on 
the  permanent  library  as  a 
change;  the  change  and  the 
structure  will  not  be  listed. 

Structure  the  RIT  RITMAHE. 

The  store  and  list  options 
are  the  saae  as  in  exaaple  1. 

Structure  the  RIT  RITNANE. 

The  newly  structured  RIT 
is  added  to  the  peraanent 
library. 

Disposition  to  be  used  for 
specials.  If  TEMP  is  des- 
ignated, the  RIT  will  be  added 
to  the  teaporary  library  and 
deleted  on  coapletion  of  the 
job. 

Designates  a debug  pass 
through  the  edit  and  trans- 
lator to  check  for  specifica- 
tion errors.  No  RIT  will  be 
structured  or  stored. 

Exaaple  of  the  use  of  the 
Boolean  logic  option. 
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7.7.3  Off-line 


The  OFFLINE  control  card  is  not  valid.  If  the  user 
desires  to  obtain  offline  print  or  punch,  he  aay  do  so  by 
overriding  the  proper  DO  cards  when  generating  the  output 
and  using  the  standard  S/360  OS  print  punch  utility  to  punch 
or  list  the  output. 


7.7.4  Publish  Special 

The  PUBLISH  SPECIAL  card  is  invalid. 


7.7.5  Publish 


There  is  a new  PUBLISH  control  card.  With  the  exception 
of  the  OFFLINE  and  PUBLISH  SPECIAL,  publis h-oriented  control 
cards  will  be  processed  and  will  produce  the  sane  effect  as 
in  NIPS  1410  FFS . The  new  PUBLISH  card  is  free  fornat, 
keyword.  Blanks  or  connas  are  treated  as  word  deliniters. 
Any  punch  in  colunn  72  indicates  a continuation.  The 
keywords  and  their  definitions  are  as  follows. 


RITID=RITNAME 

SPECIAL-RITNAHE 

ANSID=NN/BRR 


COYERPAGE»CDH 

PAGENO*NN 

BODYLIN2S-NN 

COPIES*NN 


2§f±iiiii2£ 

Identifies  naae  of  RIT  stored  on 
Permanent  Library. 

Identifies  nane  of  RIT  stored 
on  Temporary  Library  (replaces 
1410  NIPS  publish  special) . 

Identifies  a set  of  answers  to 
be  published.  NN  is  the  query 
number  and  RRR  is  the  secondary 
(RIT)  ID  used  in  RASP 

Sane  as  the  COVERPAGE  operand 
in  the  old  format  PUBLISH  card. 


Same 

as 

the 

PAGENO 

card. 

Sane 

as 

the 

BODYLINES  card 

Sane 

as 

the 

COPIES 

card. 
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CL ASS*UNCLAS SIFTED 


PARAM*' PARAM  EXAMPLE' 


DEBUG*NN 


DATE=DDMMYY 


Sane  as  the  CLASS  card.  Note 
that  if  there  are  embedded  blanks, 
the  classification  nust  be 
enclosed  in  quote  (')  signs. 

Parameter  allowing  the  user  to 
introduce  up  to  60  bytes  of 
inforaation  to  the  RIT  at  RXT 
execution  tine. 

Allows  the  user  to  designate 
the  nuaber  of  data  blocks  to  be 
passed  against  the  RIT.  Hhen  N 
is  exhausted,  an  end  of  file  or 
end  of  answer  set  is  siaulated. 

Allows  the  user  to  specify  an 
11-character  date  at  run  tine. 


Exaaple: 

PUBLISH  ANSID=1  RITID*RITEXHP  OCVERPAGE=CDW 
PAGENO*101  BODYLINES=40  C0PIES=2 


72 

X 

X 


CLASS*' VERY  UNCLASSIFIED'  X 
PARAM* ' THIS  IS  AN  EXAMPLE  OF  THE  NEN  PUBLISH  CARD'  X 
DEBUG*10 

7.8  Functional  Changes 

OFFLINE  - This  will  not  be  treated  as  an  OP  function,  but 
rather  as  a function  of  the  S/360  OS  and  the  print  punch 
utility  prograa. 

RECORD  - This  fora  of  output  will  be  set  up  as  a standard 
S/360  OS  variable  length  blocked  sequential  tape  file.  It 
will  be  set  up  so  that  at  execution  tiae  the  user  can 
override  data  set  naae,  retention,  output  device,  blocked  to 
unblocked,  and  variable  to  fixed.  The  file  will  be  closed 
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after  coapletion  of  the  RIT  (NIPS  1410  FFS  does  not  close 
until  coapletion  of  the  job). 

PSCTL  - A count  of  subsets  loaded  into  the  processing  blocks 
will  be  generated.  A RIT  which  references  the  PSCTL  will 
reference  this  count.  Note  that  only  subsets  used  by  the 
BIT  are  loaded;  i.e.,  if  the  RIT  uses  only  flagged  subsets, 
unflagged  subsets  will  not  be  loaded.  Thus,  the  NIPS  360 
FFS  PSCTL  Bight  differ  fron  the  NIPS  1410  PFS  PSCTL. 

PSSQ  - The  NIPS  360  PPS  PSSQ  differs  froa  the  NIPS  1410  PPS 
PSSQ  in  both  size  and  content.  NIPS  360  PPS  OP  will  process 
thic  field;  however,  it  perforas  no  function  to  provide 
coapatibilit y or  to  infora  the  user  of  any  possible 
incoapatibility. 

HIT  Executions  - NIPS  360  PPS  OP  differs  in  the  execution  of 
BITs  in  the  following  functions: 

An  answer  set  aay  be  executed  aany  tines  by  aany 
RITs  within  the  sane  job. 

Standard  RITs  can  be  structured  and  executed  within 
the  sane  job. 

A special  RIT  can  be  structured  once  and  executed 
aany  tines  within  the  sane  job. 

Multiple  publicaticns  of  Source  Direct  can  be 
executed  within  the  sane  job. 

RIT  Deck  Order  - NIPS  360  PPS  OP  will  check  for  proper 
stateaent  order  as  described  in  this  aanual.  Incorrect 
order  will  result  in  the  RIT  not  being  structured. 

BUN  Deck  Order  - The  order  of  the  run  deck  will  be  changed 
such  that  all  RIT  specification  decks  to  be  structured  will 
appear  first,  followed  by  the  SOURCE  card,  followed  by  the 
OP  control  cards.  Note  the  only  change  is  the  placeaent  of 
the  BIT  special  decks  and  the  ability  to  do  structures  and 
executions  in  the  sane  executions  of  OP.  Defaults  are  the 
sane  as  NIPS  1410  PPS;  e.g.,  an  execution  of  OP  with  no 
input  specification  would  result  in  the  assuaptions  that 
source  is  retrieval  and  node  is  &U* 
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Publication  Order-Source  Retrieval  - Answers  will  be 
published  in  the  order  of  the  answer  file  (QRT)  which  nay  or 
■ay  not  be  in  the  saie  order  as  the  PUBLISH  control  cards. 

Coordinates  - Automatic  conversion  of  coordinate  fields 
based  on  output  length  will  be  performed  by  OP  unless 
defined  as  a group  or  interaediate  processing  (subroutine, 
edit)  is  performed.  Also,  the  use  of  coordinate  fields  with 
the  COMPUTE,  ARITHMETIC,  COUNT,  or  CONDITION  statement  will 
be  illegal. 

Classification  - Failure  to  provide  a classification  or 
designating  a classification  which  is  not  the  sane  as  that 
designated  for  the  file  will  result  in  a warning  sassage  to 
the  operator  and  a warning  page  preceding  the  output. 

Logic  - Specification  of  BOOL  as  the  last  paraaeter  on  the 
CREATE  card  results  in  the  grouping  of  AND  terns  and  the 
separation  by  OR  teras.  The  Boolean  logic  interpretation 
thus  becoaes  consistent  with  the  retrieval  language. 
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